bug#33016: 26.1; (make-process ...) doesn't signal an error, when executable given as absolute Windows path does not exist

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Wed, 10 Apr 2019 17:58:43 -0400
> Cc: Klaus-Dieter Bauer <bauer.klaus.dieter@gmail.com>, 33016@debbugs.gnu.org
> 
> I was inspired by your suggestions to think of a simpler idea: use "C:/nul.exe".
> 
> There is unfortunately one additional wrinkle: each of the test passes
> on its own, but when running both together the second one fails due to
> this check in maybe_call_debugger:
> 
>       /* RMS: What's this for?  */
>       && when_entered_debugger < num_nonmacro_input_events)
> 
> RMS' question is (now) answered in the commentary for when_entered_debugger:
> 
> /* The value of num_nonmacro_input_events as of the last time we
>    started to enter the debugger.  If we decide to enter the debugger
>    again when this is still equal to num_nonmacro_input_events, then we
>    know that the debugger itself has an error, and we should just
>    signal the error instead of entering an infinite loop of debugger
>    invocations.  */
> 
> static intmax_t when_entered_debugger;
> 
> So I guess we'd need some way of resetting it from Lisp?

Doesn't it work to simply set its value before the second test?

> As far as I can tell, the normal debugger resets it by calling
> recursive-edit, but there's no way to return from that without human
> intervention (I think?).

Doesn't abort-recursive-edit work noninteractively?

> +                    ;; On Windows, "nul.FOO" is the empty file for any
> +                    ;; FOO, in any directory.  So this passes Emacs'

Instead of "is the empty file", I'd say something like "resolves to
the null device, reading from which sets the EOF condition".

Thanks.