bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pip Cet
Subject: bug#74966: 31.0.50; Crash report (using igc on macOS)
Date: Fri, 20 Dec 2024 20:50:56 +0000

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

>> Date: Fri, 20 Dec 2024 16:40:52 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
>> acorallo@gnu.org, spd@toadstyle.org, 74966@debbugs.gnu.org
>>
>> I meant this patch, which splits "doc" into "doc_index" and
>> "doc_offset".  It'd probably be better to use a Lisp_Object here, which
>> can be either a fixnum (index into etc/DOC) or a string (the doc string
>> specified in some other manner).  And maybe we can drop the docfile
>> index thing entirely at some point soon?
>
> TBH, I'd be much happier without splitting 'doc' into two members.
> Isn't it possible to avoid overwriting 'doc', thus avoiding the crash,
> without splitting the member in two?

Absolutely.  That'd cause wrong docstrings for some symbols, but reduce
the risk of code not compiling anymore.  There is no risk of unvetted
code compiling and accessing the doc field, because it's been renamed,
but that does require, of course, to consider the changes in the patch
as "vetted"; furthermore, if there is a compilation error in some code
I've missed, we need to be careful not to fix it without checking that
code, too.

> DOC handling in Emacs is extremely complex and has many subtle
> aspects.  Experience teaches us that bugs in this area sometimes take
> years to report and fix.  Splitting a member into two risks
> introducing bugs because we might use the wrong member in some
> situation(s).

I don't understand this specific objection.  If we rename "doc" to
"doc_offset", as I've proposed, we're automatically looking at all code
which makes use of the new field, because code using the old name no
longer compiles.

> The test suite's coverage of doc.c and features related
> to doc strings is still rudimentary, so we cannot be sure any such
> bugs will be caught in time by the tests.  Which is why I hope we can
> avoid splitting this member in two.

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?

> Thanks.

Thanks for the review!

Pip






reply via email to

[Prev in Thread] Current Thread [Next in Thread]