On 2025-03-30  20:29, Eli Zaretskii wrote:
>> Date: Sun, 30 Mar 2025 19:20:58 +0200
>> From:  Jens Schmidt via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>> [ Disclaimer:
>>
>>   - This is one of my more exotic bug reports, so I won't argue
>>     (at least not much) if you close this as "won't fix".
>>
>>   - In particular since an Emacs restart, added by Lars in
>>     5be9a9ca, probably has only been meant to be used
>>     interactively.
>>
>>   - But I do have a valid use case for a non-interactive restart,
>>     so I created this bug report ... ]
> 
> Please describe your use case.

TL;DR:

1. Start foo.el in batch mode with "emacs --script foo.el".
2. foo.el reads the user init file and writes a modified copy of
   it to init-new.el.
3. Then foo.el calls (kill-emacs ... t), thus restarting itself,
   (hopefully) still in batch mode.
4. The newly started foo.el senses the presence of init-new.el
   and, hence, processes that in a final step.

In the above it is important that steps 2 and 4 are executed
from different, newly started Emacs processes which share STDOUT
and STDERR.

The bigger picture is my package bc-dot-emacs.el

  bc-dot-emacs.el --- Check Emacs init file syntax

  https://git.sr.ht/~jschmidt/bc-dot-emacs

which I sooner or later wanted to present on emacs-devel for
inclusion to ELPA.

>> Probably Fkill_emacs should call execvp not on the command line
>> arguments in initial_argv, which already got modified by main,
>> but on a copy of the *real* initial command line arguments as
>> they have been passed into main?
> 
> Yes.  And on MS-Windows, it already does.

Indeed, I missed that bit.  The only other non-Posix case seems
to be Android, which a) IIRC does not support non-interactive
operation and b) restarts Emacs with some mechanism in Java-land
that does not require Emacs itself to keep a copy of the initial
arguments.

So this leaves the Posix/execvp case, I think, which I hope to
have covered in the attached patch.

The only thing that bothers me a bit is that there is the following
memory-related initialization being executed in main *after*
copy_raw_args (or also the present sort_args) have already been
allocating memory:

#if !defined SYSTEM_MALLOC
  /* Arrange to get warning messages as memory fills up.  */
  memory_warnings (0, malloc_warning);

  /* Call malloc at least once, to run malloc_initialize_hook.
     Also call realloc and free for consistency.  */
  free (realloc (malloc (4), 4));

#endif	/* not SYSTEM_MALLOC */

Thanks.