Re: 31395511: "Don’t attempt to modify constant strings"

[Pip Cet <pipcet@gmail.com>]

Paul Eggert <eggert@cs.ucla.edu> writes:
> On 6/4/20 4:11 AM, Basil L. Contovounesios wrote:
>> How would make-text-button detect whether its first argument is mutable?
>
> It could try to mutate the string, and catch the error that is thrown
> when it's
> not mutable.

To be honest, I'd prefer a mutablep predicate, with a strong warning not
to use it in the way that was suggested:

(if (mutablep object)
    (do-something object)
  (do-something (copy object)))

> No such error is thrown now and Emacs can crash or worse - but I
> plan to arrange for one to be thrown.

Have those plans been discussed anywhere? I get the impression it would
help me to understand what you're planning to do.

>> Would it not suffice to clarify in its documentation that it modifies
>> its argument, in the same way that we warn about passing immutable lists
>> to nconc?
>
> We could do that, yes. Some code passes string literals to make-text-button,
> though, and we'd need to change it. The first example I found was
> ibuf-ext.el's
> ibuffer-old-saved-filters-warning, which calls (make-text-button "here" ...).

> Such code is already "broken" in some sense, so we'll need to fix it
> anyway somehow.

I fail to see how that code is broken: it uses an ephemeral string
literal, just once, and gives it text properties. I don't think this is
the best way of doing things, but it's a far cry from "Emacs can crash
or worse".  Am I missing something?


>
> On 6/4/20 12:26 AM, Pip Cet wrote:
>
>> I'm not sure the copy-sequence-unless-mutable semantics really
>> make sense, though, as that might make bugs such as this one even harder
>> to find.
>
> True.
>
>> I think we should add a new function with clean semantics, and throw an
>> error in the old function if the string isn't "mutable", whatever that
>> means in this context.
>
> Throwing an error matches Basil's suggestion. What sort of clean semantics did
> you have in mind?

Well, a documented return value would be a good start.  The "BEG can be
a string, in which case it's really the object, and we'll return it"
thing is confusing, I think.

I would suggest two functions, one which propertizes a string to be a
button when inserted, and returns the propertized string; and one which
adds text properties to make a range of an object (string or buffer)
into a button, and doesn't return anything useful.

>> (I guess I can't modify the string contents or
>> add text properties, but can I modify existing properties?  What about
>> cons cells deep within the properties? If they're recursively immutable,
>> what about markers and other objects that change state behind your
>> back?)
>
> The test I was thinking of is pretty simple: you can't modify the
> string object
> itself, but you can modify the objects it points at.

I think I can kind of decrypt that, but I'm not sure: keep in mind that
currently, for example, (text-properties-at N STRING) returns the
string's actual plist, so you can mutate it, which seems useless and
potentially dangerous to me. (Please, let's change that?)

Would you consider (text-properties-at N STRING) to be part of the
string object itself, or an object it points at?

> We could come up with
> fancier tests later involving immutable property lists, but one thing
> at a time
> and maybe this one thing is good enough (at least it should avoid the
> undefined
> behavior).

Which undefined behavior is that, precisely? It seems to me it would be
pretty easy to define current behavior, though it wouldn't be very
useful.

>> I'm still surprised my patch fixed the problem here (for some buttons,
>> at least, for others there are a few more places that do the same
>> thing...) but not for João.
>
> There are several instances of the same problem in SLY. I found the
> ones in the
> attached patch, and I expect there are others. So perhaps João was
> running into
> one of the other problems.

I think that was what was happening, yes.