Handling argc==0 in the kernel [LWN.net]

Handling argc==0 in the kernel

Posted Jan 31, 2022 8:53 UTC (Mon) by anselm (subscriber, #2796)
In reply to: Handling argc==0 in the kernel by marcH
Parent article: Handling argc==0 in the kernel

First, a brief reminder that some standard requires argv[argc] to be NULL would be IMHO very useful.

FWIW, my venerable copy of ANSI/ISO 9899-1990 says, in section 5.1.2.2.1:

argv[argc] shall be a null pointer.

Perhaps this was changed in the meantime but I would be surprised.

It's not obvious that it does because why would you need a clumsy NULL terminator when you already have a proper argc?

Presumably so you can say char **p; for (p = argv; *p; p++) {…}. One might argue that this is superfluous and that people ought to be doing something like int i; for (i = 0; i < argc; i++) {…} instead, but chances are that in the run-up to ANSI/ISO 9899-1990 there were C implementations that did guarantee argv[argc] == 0 already, and the former idiom was sufficiently widespread that it was easier to mandate this for everyone than to outlaw (or leave vague) something that worked fine for a large enough number of people.

to post comments

Handling argc==0 in the kernel

Posted Jan 31, 2022 9:55 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (1 responses)

I would bet that there was somebody who insisted that one or the other of those loops was 2% faster on architecture X (for some value of X), and therefore demanded that it be allowed.

I would tend to assume that the int loop is marginally easier to branch-predict? But I'm somewhat skeptical that that was relevant on the hardware of the time...

Handling argc==0 in the kernel

Posted Jan 31, 2022 11:19 UTC (Mon) by mfuzzey (subscriber, #57966) [Link]

Especially as the time spent processing the argument list is likely to be negligable compared with the time doing the exec() and all the subsequent setup of the new process (loading shared libraries etc). The strace output for hello world is quite "frightening"...

Handling argc==0 in the kernel

Posted Jan 31, 2022 13:14 UTC (Mon) by jem (subscriber, #24231) [Link] (6 responses)

One might also argue that argc is superfluous, and iterating over argv by incrementing a pointer variable, stopping when the terminating NULL is reached, would be the idiomatic C thing to do. After all, this would be analogous to how C's null-terminated strings are handled.

Handling argc==0 in the kernel

Posted Jan 31, 2022 19:10 UTC (Mon) by marcH (subscriber, #57642) [Link] (5 responses)

> One might also argue that argc is superfluous, ...

Yes and that would be very ironic in an article about a pkexec security issue caused by not using argc as termination and fixed by looking at it :-)

Anyway comparing termination in C versus all other programming languages was not my point. Using _both_ argc and NULL at the same time is idiomatic in exactly zero programming language, so that's confusing. So I'm merely suggesting adding one short sentence about that.

Handling argc==0 in the kernel

Posted Jan 31, 2022 19:42 UTC (Mon) by nybble41 (subscriber, #55106) [Link] (4 responses)

> caused by not using argc as termination

One could equally well cast this issue as "caused by not checking the first element of the array for the NULL terminator". It's exactly the same error as if you received a NUL-terminated string and started iterating over it from the second element, assuming the string to be non-empty.

I'm in the Pascal-style string/list camp myself—lengths should be explicit—but using argc instead of checking for NULL is neither necessary nor sufficient to avoid this problem. (To illustrate the latter, consider the case of a program making the same non-empty argv assumption and using a loop of the form "int i = 1; do { ... } while (i++ < argc)" to shave off a "redundant" bounds check.)

Handling argc==0 in the kernel

Posted Jan 31, 2022 19:57 UTC (Mon) by marcH (subscriber, #57642) [Link] (3 responses)

> One could equally well cast this issue as "caused by not checking the first element of the array for the NULL terminator". It's exactly the same error as if you received a NUL-terminated string and started iterating over it from the second element, assuming the string to be non-empty.

It's "exactly the same" only if your termination looks like "i != argc" but no one ever does that. Everyone does "i < argc" or something like it. I mean no one writes:

for (int i; i++; i!=argc)

> but using argc instead of checking for NULL is neither necessary nor sufficient to avoid this problem.

I haven't looked at the actual code but if pkexec's loop had used an argc-based termination then the loop would have not run at all.

> int i = 1; do { ... } while (i++ < argc)" to shave off a "redundant" bounds check.)

That's bending over backwards to avoid a simpler for loop. I'm sure you can find some real world and valid cases for this but most of the time people just write a simpler for loop.

Handling argc==0 in the kernel

Posted Jan 31, 2022 22:19 UTC (Mon) by marcH (subscriber, #57642) [Link]

> for (int i; i++; i!=argc)

Of course I meant no one writes this:

for (int i=start; i!=argc; i++)

Sorry for the noise.

Handling argc==0 in the kernel

Posted Feb 1, 2022 1:58 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (1 responses)

> It's "exactly the same" only if your termination looks like "i != argc" but no one ever does that. Everyone does "i < argc" or something like it. I mean no one writes:
>
> for (int i; i++; i!=argc)

Maybe not in C, but C++ tacitly encourages this sort of nonsense because iterators are not, strictly speaking, required to be ordered (for example, a linked-list iterator may only be comparable for equality, because there is no O(1) way of ordering two iterators). So if you're taking C++ code and porting it to straight C, the most straightforward translation of a foreach loop is to use an inequality comparison instead of a less-than comparison, and it's possible that some programmers who started out as C++ programmers and later learned C may have picked this up as an idiom.

(Incidentally, these people also tend to favor the preincrement operator over the postincrement operator in contexts where there's no semantic difference, because in C++, postincrement can be significantly costlier due to the need to make a copy.)

Handling argc==0 in the kernel

Posted Feb 1, 2022 12:59 UTC (Tue) by madscientist (subscriber, #16861) [Link]

In my experience with C++, people use < most of the time when looping over integers. You can't perform integer looping with an iterator, unless you add your own specializations which people don't really bother to do, so these kinds of loops are written differently than loops with STL iterators anyway.

Also even in C, old-school programmers preferred pre-increment because post-increment was less efficient. Of course it was hard to detect that inefficiency, but it was a peg to hang one's preferential hat on and that's all that's needed when faced with two essentially equivalent choices. In C++ with operator overloading it can be measurably less efficient, of course, depending on the type implementation.