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

[Paul Eggert]

On 6/4/20 1:43 PM, Pip Cet wrote:

> I'd prefer a mutablep predicate, with a strong warning not
> to use it

I'd rather not not build/support/advertise predicates that shouldn't be used....

>> 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.

A few weeks ago, a bit. The idea I have is pretty simple: the Emacs interpreter
throws an error if you attempt to modify a string constant. Although the
interpreter done this for years, (a) its test for whether a string is a constant
has always been spotty and (b) the test has gone downhill recently.

> I fail to see how that code is broken: it uses an ephemeral string
> literal

String literals are not ephemeral; they can be coalesced, or retained, or put
into read-only memory. And when Emacs does that your program's behavior becomes
squirrelly.

> 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.

Yup.

> 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'm no expert on make-text-button etc. so I'll let the experts comment on that 
one.

> (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?)

We could do something along those lines eventually. The immediate problem that
I'm looking at is just the string itself.

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

My earlier email was assuming the current implementation, which is the latter.
However, I don't think this matters much, since string literals shouldn't have
text properties.

> Which undefined behavior is that, precisely?

I was referring to code that modifies literal strings' contents or properties.
We don't really define how that works, and in practice it doesn't work the way
people might naively expect since strings might be coalesced and their contents
might be in read-only memory.