When can argv[0] have null?

What I have understand about passing arguments to main() from command line is that argc has a minimum value of 1 and argv[0] will always have the program name with its path in it. If arguments are provided at the command line, then argc will have a value greater than one and argv[1] to argv[argc-1] will have those arguments. Now a paragraph at this link says that

argv[0] will be a string containing the program's name or a null string if that is not available.

Now, how and when can argv[0] have null string? I mean program name with its path will always be available so when can it be null? Writer says that "if that is not available" but when and how it is possible that program name will not be available?

@Ciro Santilli 烏坎事件2016六四事件 法轮功 - Looking at the asked and answered dates, you'll see that this question is a duplicate of stackoverflow.com/questions/2336027/why-check-if-argv-null, not the other way around.

@ShaunHamman Current consensus is to close by "quality": meta.stackexchange.com/questions/147643/… Since "quality" is not measurable, I just go by upvotes. ;-) Likely it comes down to which question hit the best newb Google keywords on the title.

4 Answers 4

With the exec class of calls, you specify the program name and program executable separately so you can set it to NULL then.

But that quote is actually from the ISO standard (possibly paraphrased) and that standard covers a awfully large range of execution environments from the smallest micro-controller to the latest z10 Enterprise-class mainframe.

Many of those embedded systems would be in the situation where an executable name makes little sense.

From the latest c1x draft:

The value of argc shall be nonnegative.

The value argv[argc] shall be a null pointer.

If the value of argc is greater than zero, the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program start up.

This means that, if argc is zero (and it can be), argv[0] is NULL.

But, even when argc is not 0, you may not get the program name, since the standard also states:

If the value of argc is greater than zero, the string pointed to by argv[0] represents the program name; argv[0][0] shall be the null character if the program name is not available from the host environment. If the value of argc is greater than one, the strings pointed to by argv[1] through argv[argc-1] represent the program parameters.

So, there is no requirement under the standard that a program name be provided. I've seen programs use a wide selection of options for this value:

• no value at all (for supposed security).
• a blatant lie (such as sleep for a malicious piece of code).
• the actual program name (such as sleep ).
• a slightly modified one (such as -ksh for the login shell).
• a descriptive name (e.g., progname - a program for something ).

I'd swear I just heard someone say, "Warp factor one, Mr. Sulu" when reading "Enterprise-class mainframe".

The Morris Worm also changed its argv[0] iirc. That worm had a lot of clever bits in it as I am sure you know.

Runnable POSIX example of argv[0] == NULL

#define _XOPEN_SOURCE 700 #include int main(void) < char *argv[] = ; char *envp[] = ; execve("callee.out", argv, envp); > 

#include int main(int argc, char **argv)

gcc -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o caller.out caller.c gcc -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o callee.out callee.c ./caller.out 

Test existing program with empty argument list

Here's a wrapper that takes a path as its argument, and runs that as a command with no args:

#include #include int main(int argc, char**argv) < char *empty[] = ; execve(argv[1], empty, empty); > 

./caller-any.out /bin/ls 

GNU Coreutils tools like ls however have a check for argv[0] NULL as mentioned at: Why can the execve system call run "/bin/sh" without any argv arguments, but not "/bin/ls"? and ls outputs:

A NULL argv[0] was passed through an exec system call. Aborted (core dumped) 

Tested in Ubuntu 19.04.

According to this mailing list, argv[0] can be null if argc == 0 . But they don't explain when argc might ever be zero. I would suspect argc would be zero in situations where an executable was not launched "normally" (i.e. through a command line, popen , etc.) -- and indeed, as @paxdiablo mentioned, you can manually set argv with the exec family of functions, so argc could be zero depending on those arguments.

But, in their Rationale section:

Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word should, requires a Strictly Conforming POSIX Application to pass at least one argument to the exec function, thus guaranteeing that argc be one or greater when invoked by such an application. In fact, this is good practice, since many existing applications reference argv[0] without first checking the value of argc .

So there you have it: Strictly Conforming POSIX Applications must have argc be greater than zero, but that is otherwise by no means guaranteed.

There's a little more information on the standard regarding argc and argv in the Program Startup section.