The only way that condition happens is if the program is being exploited. You cannot, for instance, trigger it from a shell. Here, argc is less than 1. There have been multiple attempts to get the kernel to EFAULT when execve() is called this way, because a NULL argv has utility principally as a gadget in shellcode and nowhere else. EFAULT is what FreeBSD and OpenBSD do when you try to execute a program with a NULL argv.
Fault them for not changing the loop, which has clearly busted logic, and adding a guard clause instead. But you can't fault them for not providing a user friendly error to shellcoders. The condition here isn't simply "too few arguments".
Can't you exec() this and run it with zero arguments?
Either way: when in doubt, best to print a message! You're right this specifically probably isn't the biggest issue, but in general it seems to be design with "this should never happen, just exit/deny" in mind, and turns out that in some odd cases those things do happen.
The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.
I don't think this is a bad argument at all. It wouldn't kill anyone to include a brief stderr worthy message along with the exit. Especially when, and correct me if I'm wrong, code 126 is pretty vague here. "Command not executable" doesn't seem even correct to me.
The entire point of Unix exit codes is to communicate enumerated errors to programmers without having them have to intercept stderr and parse unstructured output. But to spot this error, of "I literally don't know how to use execve", all you need to do is look for the nonzero exit code.
I suspect that the person who kicked this subthread off didn't realize that the error can't be triggered from the shell (like, they thought it was "insufficient arguments" and not "malformed input to execve"), and now we're just bikeshedding a justification for being angry at Unix error codes. Seems like not a super valuable discussion to have.
One good reason not to have a user-friendly error message here is that literally no user will ever see it. In fact: it's likely that in the entire history of this program, it has never once been executed in the fashion that would generate this error, except to exploit it.
Again this is indeed a bike-shedding conversation but how hard is it to print an error message along with the error code? Seems harmless enough and just one more line of code.
Fault them for not changing the loop, which has clearly busted logic, and adding a guard clause instead. But you can't fault them for not providing a user friendly error to shellcoders. The condition here isn't simply "too few arguments".