bug#74966: 31.0.50; Crash report (using igc on macOS)

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Pip Cet <pipcet@protonmail.com>,  spd@toadstyle.org,  acorallo@gnu.org,
>   monnier@iro.umontreal.ca,  74966@debbugs.gnu.org
> Date: Sat, 21 Dec 2024 08:08:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I agree that the docfile hack in general is very hairy territory.  It
> >> might be safer to simply accept the wrong docstrings for now, and Gerd's
> >> patch does that, IIUC.  Can we just apply that for now and add a FIXME?
> >
> > Maybe, but I'd like first to understand better the "wrong docstrings"
> > situations.
> 
> Maybe I can explain this. The current error's cause is that nativecomp
> currently (wrongly) assumes that it never needs an offset into DOC, so
> it reused Lisp_Subr::doc for its own purposes, namely as an index into a
> vector contained in an .eln file. The doc string of a function is found
> at that index.
> 
> Pip's patch changes nativecomp code stores the said index from above in
> a new Lisp_Subr::doc_index, and makes it possible to fix the wrong
> assumption from above, Nativecomp of course has to check which of the
> now two members it has to use, which Pip does.
> 
> Renaming Lisp_Subr::doc to Lisp_Object::doc_offset is a nice extra, IMO,
> because it makes it clearer what the member contains.

OK, thanks.  I'd like Andrea to chime in first and see if he can fix
this on the nativecomp side.

Also, Stefan said something about using a Lisp_Object for the value?

And finally, does what you wrote explain the "wrong docstrings"
situation, or does it only explain the crash you saw?  If the former,
I'm afraid I'm still missing something, because I don't understand how
this could cause a wrong docstring to be used.