When can argv[0] have null?

Question

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?

Highspirited

@Ciro Santilli 烏坎事件2016六四事件 法轮功 - Looking at the asked and answered dates, you'll see that this question is a duplicate of https://mcmap.net/q/176244/-why-check-if-argv-null-duplicate, not the other way around. – Mucoprotein

@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. – Pileum

Answer 1

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).

Komsa

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

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. – Radical

Answer 2

Runnable POSIX example of argv[0] == NULL

caller.c

#define _XOPEN_SOURCE 700
#include <unistd.h>

int main(void) {
    char *argv[] = {NULL};
    char *envp[] = {NULL};
    execve("callee.out", argv, envp);
}

callee.c

#include <stdio.h>

int main(int argc, char **argv) {
    if (argc == 0 && argv[0] == NULL)
        puts("yup");
}

Then:

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

Output:

yup

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:

caller-any.c

#include <unistd.h>
#include <stdio.h>

int main(int argc, char**argv) {
    char *empty[] = {NULL};
    execve(argv[1], empty, empty);

}

Sample usage:

./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.

Pileum

Answer 3

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.

Meghanmeghann

You're summarizing the requirement backwards. Strictly Conforming POSIX Applications called from other Strictly Conforming POSIX Applications can depend on argc>0 and argv[0] != NULL. They must also call execve and related functions in a way that maintains that guarantee for the child process. But nothing stops a malicious user from running your strictly-conforming program with argc == 0 on typical existing POSIX systems. If it's setuid or has any other special privileges, either check argc or the pointer, or make sure that a segfault on access to argv[0] won't break anything. – Intestate

Answer 4

It's possible to imagine platforms where programs do not have names - perhaps the code is simply loaded at startup. On those, argv[0] could I guess be NULL. The C Standard certainly allows an argc value of zero, and says that argv[argc] shall be NULL.

Ironmonger