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

[Eli Zaretskii]

> 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
here. Andrea suggested a change that he prefers, and from where I
stand, we should wait for him to publish such a patch.  Then we can
discuss the patch if there are comments or objections.  But let's do
all that in the bug thread, not here.

Apologies if I misunderstood what the above is about.