bug#27642: 26.0.50; Assertion failure with nested load

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 27642-done@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.  */)
    (void)
  {
    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?

TIA