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

[Pip Cet]

Paul Eggert <eggert@cs.ucla.edu> writes:

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

It's perfectly usable in most situations, it's just that you shouldn't
use it to decide whether your function has side effects or not.

>>> 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 think there was only CHECK_IMPURE, which relies on PURE_P, which is
effectively a nop in post-dump binaries. (I still think we should remove
pure space entirely, but even if we don't we should stop wasting so much
binary size on zeroes. But let's wait for Emacs 27 first, as Eli
suggested).

>> I fail to see how that code is broken: it uses an ephemeral string
>> literal
>
> String literals are not ephemeral;

I still believe this one is. It's used in a top-level form in a defvar.

> they can be coalesced, or retained, or put into read-only memory.

Really? Is there code in Emacs (other than purecopy, which isn't the
problem here) that does any of that today?

> And when Emacs does that your program's behavior becomes squirrelly.

If Emacs were to, a lot of code would break, yes. IMHO, that's a good
reason to leave things as they are for now, deal with the pure space
issues first, and then decide whether immutable objects are worth it at
all...

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

But if text properties aren't part of "the string itself", they can be
given 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.

You're saying "in practice ... their contents might be in read-only
memory"? How?