[TUHS] the first busybox

[segaloco via TUHS]

On Thursday, October 22nd, 2026 at 14:23, Steffen Nurpmeso via TUHS <tuhs at tuhs.org> wrote:

> And today "they" ("we") are about to add some getexecpath() into
> standards, and certain BSDs have week long runs to remove argv[0]
> in favour of that function in all programs (at least daemons) of
> the base system.  (Not to distress anyone again because of my
> shock not to ever have though about that argv can be NULL.)
> 
> --steffen

Interesting, had a double take at this one.  Took a look at ANSI and
indeed it looks like this can happen.  ANSI C says argc must be
non-negative, but can be zero apparently.  Only if it is non-zero then
is argv[0] guaranteed to be a pointer to a string representation of the
name of the invoked program.  Was this made flexible for environments in
hosted environments in which there is no way (or desire) to pass this
information to main()?  I could see this being the case for freestanding
environments, but an extension like POSIX I imagine wouldn't be layered
on top of a freestanding environment anyway.

That said, I looked further and interestingly the April 1986 Trial Use
copy of POSIX 1003.1 in section 3.1.2.2 gives the main(argc, argv)
signature with a note:

> where argc is the argument count (one or greater), argv is an array
> of character pointers to the arguments themselves...

whereas the final from 1989 gives:

> where argc is the argument count and argv is an array of character
> pointers to the arguments themselves.

So the "one or greater" note is dropped.  Either way, both then go on to
say:

> The value in argv[0] should point to a filename that is associated
> with the process being started by one of the exec functions.

So is this to imply along the way to POSIX they acknowledged that ANSI C
does not guarantee argc > 0 and argv != NULL and decided to align?

- Matt G.