Re: Merging scratch/no-purespace to remove unexec and purespace

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

"Pip Cet via \"Emacs development discussions.\"" <emacs-devel@gnu.org> writes:

> "Stefan Kangas" <stefankangas@gmail.com> writes:
>
>> Pip Cet <pipcet@protonmail.com> writes:
>>
>>> "Stefan Kangas" <stefankangas@gmail.com> writes:
>>>
>>>> Pip Cet <pipcet@protonmail.com> writes:
>>>>
>>>>> What I think we should do doesn't really matter, but it seems quite
>>>>> obvious to me that we should make the code on the master branch
>>>>> perform all three checks on all relocations, as the code on
>>>>> no-purespace does.
>>>>
>>>> Maybe.  But won't we get those checks with no additional effort once we
>>>> merge no-purespace,
>>>
>>> Yes, we will.  (And the forbidden symbol; even if the forbidden symbol
>>> doesn't cause trouble, which I think it will, it's simply very poor
>>> programming practice to do things that way, particularly since the
>>> crash may happen a long time after the compilation.  But, again, what I
>>> think obviously doesn't matter here.  I'll just remember that
>>> --enable-checking causes false positive crashes and shouldn't be used).
>>
>> I don't think the existence of one symbol that will crash Emacs in some
>> situations means that --enable-checking should be completely avoided.
>> It's still quite useful, and we're fine as long as we avoid using that
>> one symbol, right?
>>
>> OTOH and IMHO, it would be preferable if that symbol could not crash
>> Emacs.  Can we come up with a good way to fix that, while preserving the
>> check that Andrea wants to keep?
>
> That sounds like a good thing to focus on, yes.  We need to have a value
> in a vector that we Fread that is distinguishable from all other values.

I just reread the code, and #$ may be what we're looking for.  It's a
unique value that we can pass in to Fread (let-binding load-file-name),
and it already exists.  OTOH, it's used for docstrings normally, so it
may be cleaner to invent new read syntax.

I'd really like to fix this.

> For example, right now this code doesn't work:
>
> (let ((print-circle t) (read-circle nil))
>   (message "%S" (funcall (native-compile (lambda () #1=[#1#])))))
>
> (read, of course, with read-circle bound to t)
>
> but this does:
>
> (let ((print-circle t) (read-circle nil))
>   (message "%S" (funcall (lambda () #1=[#1#]))))
>
> So this seems like a cheap drive-by fix.

The non-nativecomp code also breaks if read-circle is nil (I assume this
is related to autoload), so it isn't just the nativecomp code that
should be fixed.

Pip