>First, you can pass in a zero-length argv (ie, where argv[0] is NULL), in which case the executed program will have an argv[0] that is NULL. A variety of programs will then be unhappy with you, as people discovered in CVE-2021-4034. This option exists more or less because this API was easy back in the old days of Unix.
Input validation, unsound assumptions, relying on magic values (NULL termination)
Classic array bounds error. Obviously, if argc == 0, you should not dereference anything in argv.
It also shows why C is such a hard programming language. There is nothing to help the programmer in this case. The compiler doesn't know that argc is the length of argv, so there is not even a warning if you do it wrong.
If you are writing a C program, then you should consult the C standard, and possibly POSIX. The Linux kernel + C runtime + C compiler should form a conforming implementation of the C language.
Now if the Linux kernel doesn't promise to pass a non-NULL argv (and documents so), then it should be the responsibility of the C runtime to fix that once the program reaches "main". But as I wrote earlier, it's a whole other question.
Why does it even matter what the POSIX standard says? The C standard dictates that `argv[argc] == NULL`, and hence argv shall always be differentiable. Thus, it is very clear that the C standard was violated by the previous Linux+crt. What POSIX says is entirely irrelevant here - if I write a standard C program, not a POSIX program, and it fails to run on the platform, then that platform has violated the C Standard.
Because you haven't grasped it either. No-one is saying that argv[argc] != NULL. But in the case being discussed by M. Siebennmann, argc is 0.
The Single Unix Specification says, very clearly:
> The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions.
> The value in argv[0] should point to a filename string that is associated with the process being started by one of the exec functions.
Then it goes on at length in the rationale at the bottom of that same section about "the use of the word should" and even explains how programs are tripped up by argc being 0.
As you can see, both masfuerte and planede have still clearly not read this, despite that it's said twice in the description, and then has two entire paragraphs devoted to the reasoning underpinning it in the rationale.
I really don't know what you're trying to argue here.
Yes, that spec places additional requirements on top. But looking at just the C spec is apparently enough to find a violation here, and that's relevant! (Especially because the C spec doesn't say "should".)
People wanting to point that error out doesn't mean they're failing to grasp anything.
Think it through. Yes, both you and xe haven't grasped this. M. Siebennmann's scenario is that argc is 0, and argv[0] is NULL. There's nothing in the quoted
> argv[argc] shall be a null pointer.
constraint that that violates. argv[argc] is a null pointer. You have not found a violation of that constraint.
The constraint that is violated is, rather, in the Single Unix Specification. It's the SUS that puts the constraint upon how execve() may be invoked by a strictly conformant application, and requires that (as it says twice) argc be "one or greater", because it constrains the first element of the argument vector to be a pointer to a string, not a null pointer. The _only_ leeway is the wiggle room in "associated with", which it devotes an entire paragraph to explaining.
More than one standard applies. The idea that only the C standard covers the writing of these programs is wholly wrongheaded. After all, the C standard also allows non-POSIX implementations.
One scenario is that argc is 0 and argv[0] is NULL.
The other scenario is that argc is 0, argv is NULL, and argv[0] does not exist.
The C standard makes the second scenario invalid, but Linux was allowing it.
This is all directly relevant to the first two posts in the comment thread, talking about "relying on magic values (NULL termination)" and "Obviously, if argc == 0, you should not dereference anything in argv. [...] shows why C is such a hard programming language". Even though they were talking about C by itself, that's actually incorrect, C guarantees the null termination and this rule was being broken by the OS.
> The meanings specified in POSIX.1-2017 for the words shall, should, and may are mandated by ISO/IEC directives.
By those directives "should" indicates recommendation. [1]
> In POSIX.1-2017, the word should does not usually apply to the implementation, but rather to the application. Thus, the important words regarding implementations are shall, which indicates requirements, and may, which indicates options.
You also have to differentiate between any requirements for the argv argument when passed to one of the exec functions and the argv parameter received in main. Any requirement for the former constrains the application, but requirements for the latter constrains the implementation.
exec is indeed only documented in POSIX and OS specific documentations, but main is also documented in ISO C. Both POSIX and ISO C constrains the argv parameter of main not to be null. They don't require argc > 0 or argv[0] != null.
From [2]:
> [under exec] The argument argv is an array of character pointers to null-terminated strings.
This is a hard requirement, without "should". This implies that argv must not be null itself when passed to exec. This probably gives implementations the freedom to do whatever in this case, POSIX doesn't define the behavior. The requirement for argv[0] (which implies argc > 0) is merely a recommendation.
So I just looked at the POSIX standard for the exec functions. It says the argv array is terminated by a null pointer when it arrives at the C main function. But a null argv doesn't cause exec to fail. Which implies that the OS or C runtime must fix it up between exec and main.
> [under int main (int argc, char *argv[]);] The argv and environ arrays are each terminated by a null pointer. The null pointer terminating the argv array is not counted in argc.
This confirms that the argv function parameter of main cannot be null.
I couldn't find the behavior specified for passing null for argv in exec*. As other comments pointed out some BSDs return with EINVAL. I think both this and Linux's behavior is compliant.
"Obviously, if argc == 0, you should not dereference anything in argv."
I'd say that's not obvious. Normally argv is null-terminated so you can read argv[argc], and it's zero. There's no need to read argv[argc] if you've already looked at argc but sometimes it's more convenient to rely on the sentinel value.
Wait what bugs are caused by argv's null termination? Aren't all these bugs caused by the fact that argc can be 0 and programs don't expect that, not that argv is null terminated?
Input validation, unsound assumptions, relying on magic values (NULL termination)
Boring stuff still causes damage