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

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

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Fri, 03 Jan 2025 22:36:42 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Stefan Kangas <stefankangas@gmail.com>, Andrea Corallo
>> <acorallo@gnu.org>, Gerd Möllmann <gerd.moellmann@gmail.com>, Eli
>> Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca
>>
>> "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.
>
> Is this about bug#74966?  If so, let's not discuss the same issue

No.  This is about the --enable-checking code treating --lambda-fixup as
a forbidden symbol and crashing if it is used in the obvious fashion by
any code that happens to be native-compiled, which is the current status
on scratch/no-purespace.

Pip