bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere

[Stefan Monnier]

>> >> The manifestation of the problem will be that modify_region will be
>> >> called in this case, although we don't actually modify anything.  You
>> >> will probably see the "modified" indicator on the mode line, something
>> >> that shouldn't have happened.
>> > That is indeed what happens.
>> > OTOH, the existing behavior in this area is rather messy anyway:
>> Not only that, but it's not clear why "that shouldn't have happened".
> Because we announce that the buffer was changed when in fact it
> wasn't.  That's a lie.  (It also causes redisplay to work harder as a
> side effect.)

That's a widespread "lie".  E.g. turn on overwrite-mode and replace the
char at point with itself: sure enough the buffer is marked as modified.
Along the same lines, try (setq t t) and watch how it complains that
we're trying to modify a read-only object, ...

> You can repeat the last 2 steps forever, the buffer always becomes
> modified.  I don't see how this could be anything but a bug.  Not a
> catastrophe, I agree, but a bug nonetheless.

add-text-property is a mutation operation, like setq.  Whether or not it
returns data about the "old state" doesn't make it less of
a side-effecting operation, in my eyes.  So, no I do not consider it to
be a bug at all.

Try (add-text-properties 2 10 '(foo nil)) for another corner case: the
`foo' property was already nil (by default), and yet add-text-properties
claims that setting it to nil is a modification.

>> And I don't think it's an important one here, since (as Dmitry points
>> out) the likely most common case (of having `start' be right at the
>> beginning of an interval object) didn't work anyway
> It does work now.  More importantly, it fixed the original crash.

I suspect it only works around the crash by optimizing away the call
to modify_region in the particular case you're testing.

>> and furthermore most calls to add-text-properties are likely to be
>> protected by inhibit-modification-hooks.
> I don't think inhibit-modification-hooks stops the file-locking prompt
> from being shown, does it?

Well, I meant not just inhibit-modification-hooks but
with-silent-modifications (or a comparable set of let-bindings and
unwind-protect), which does prevent the prompt.


        Stefan