[Top][All Lists]

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

bug#27642: 26.0.50; Assertion failure with nested load

From: Eli Zaretskii
Subject: bug#27642: 26.0.50; Assertion failure with nested load
Date: Thu, 13 Jul 2017 21:08:25 +0300

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Wed, 12 Jul 2017 14:25:00 -0700
> On 07/12/2017 07:52 AM, Eli Zaretskii wrote:
> > I guess the safety harness installed by Paul should be improved to
> > support recursive calls to 'load'.  Until then, I installed a
> > temporary work-around, just to let people who build with assertions
> > enabled work in Emacs without crashes in these cases.
> Your fix is not merely a temporary workaround, as it should work even if 
> there are recursive calls with errors. Closing the bug report, and thanks.

Glad I could fix this, but something is still bothering me.

AFAIU, the infile object is used throughout lread.c, and the places
that use it insist on it not being a NULL pointer.  Example:

  DEFUN ("get-file-char", Fget_file_char, Sget_file_char, 0, 0, 0,
         doc: /* Don't use this yourself.  */)
    if (!infile)
      error ("get-file-char misused");

Next, my reading of the code is that close_infile_unwind is normally
called whenever Fload returns.  So if there is a recursive call to
Fload, the inner call will clobber the value of infile set by the
outer call, and when the inner call returns, infile will become a NULL
pointer when close_infile_unwind is called.  Doesn't that get in the
way of the outer call, if it then tries to resume its readevalloop?
Or did I miss something?


reply via email to

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