From: already5chosen@yahoo.com   
      
   On Tue, 30 Dec 2025 19:35:12 -0800   
   Keith Thompson  wrote:   
      
   > Michael Sanders  writes:   
   > > On Tue, 30 Dec 2025 18:42:30 GMT, Scott Lurndal wrote:   
   > >> What if 'argv[0]' is NULL (and argc == 0)?   
   > >   
   > > Well, seems we have to make a choice, ISO vs. POSIX:   
   > >   
   > > *ISO C (C17 / C23)*:   
   > >   
   > > C17, 5.1.2.2.1 "Program startup"   
   > >   
   > > The value of argc shall be nonnegative.   
   > >   
   > > argv[argc] shall be a null pointer.   
   >   
   > [...]   
   >   
   > > *POSIX.1-2017 (and later)*   
   > >   
   > > POSIX execve() specification:   
   > >   
   > > The argument argv is an array of character pointers   
   > > to null-terminated strings.   
   > >   
   > > The application shall ensure that argv[0] points to a filename   
   > > string that is associated with the process being started.   
   >   
   > [...]   
   >   
   > > What say you?   
   >   
   > It happens that I recently spent some time looking into this.   
   >   
   > As you say, POSIX requires argc >= 1, but ISO C only guarantees   
   > argc >= 0.   
   >   
   > If argc == 0, a program that assumes argv[0] is non-null   
   > can run into serious problems if that assumption is invalid.   
   > In particular, a program called "pkexec" would try to traverse   
   > arguments starting with argv[1], which logically doesn't   
   > exist if argc==0.  Due to the way program arguments are laid   
   > out in memory, argv[1] is also envp[0].  Frivolity ensued.   
   > See .   
   >   
   > The Linux kernel updated execve to ensure that the invoked program   
   > has argc>=1.  It was patched in early 2022.  NetBSD still has this   
   > vulnerability.   
   >   
   > Summary: Some systems guarantee that argc>=1 and argv[0] points to   
   > a valid string, but software that's intended to be portable should   
   > tolerate argc==0 and argv[0]==NULL.   
   >   
   > For more information, see   
   > .   
   >   
      
   If you are interested in behavior on non-POSIX systems, primarily   
   Windows, but possibly others as well (e.g. VMS) then using exec() in   
   caller sounds like a bad idea. It just not how these systems work and   
   not how people write programs on them.   
   Even when exec() *appears* to works in some environments (like   
   msys2) it likely emulated by spawn() followed by exit().   
      
   I'd implement caller with spawn(). I suppose that even on POSIX it is   
   more idiomatic.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)