Why is argc not a constant?

Question

int main( const int argc , const char[] const argv)

As Effective C++ Item#3 states "Use const whenever possible", I start thinking "why not make these 'constant' parameters const"?.

Is there any scenario in which the value of argc is modified in a program?

Frampton

You are free to declare argc as const. – Nakesha

I have seen many production quality code that do this: --argc – Hoeve

I'm thinking it has to do with C legacy, but wouldn't know how. – Occupation

See an example: opensource.apple.com/source/awk/awk-1.2/main.c – Andi

@LuisMachuca obviously C is born before C++ – Carpous

I suspect that "Use const whenever possible" refers to things passed by reference, where any modification within the function persists once the function has exited. This is not true with things passed by value, like an integer, so there's nothing to be gained by making it const; indeed, passing argc as a const int means that you can't then use argc as, say, a counter inside the function. – Acescent

@SteveMelnikoff : I don't agree that there is nothing to gain by making const a pass-by-value parameter. See eg https://mcmap.net/q/205041/-isn-39-t-quot-const-quot-redundant-when-passing-by-value-duplicate and https://mcmap.net/q/47099/-does-using-const-on-function-parameters-have-any-effect-why-does-it-not-affect-the-function-signature – Andi

The historical explanation is that main's function signature is unchanged since the days of Unix 7, and there was no const back then (it was a shiny new feature of C89). – Dutiful

Answer 1

In this case, history is a factor. C defined these inputs as "not constant", and compatibility with (a good portion of) existing C code was an early goal of C++.

Some UNIX APIs, such as getopt, actually do manipulate argv[], so it can't be made const for that reason also.

^{(Aside: Interestingly, although getopt's prototype suggests it won't modify argv[] but may modify the strings pointed to, the Linux man page indicates that getopt permutes its arguments, and it appears they know they're being naughty. The man page at the Open Group does not mention this permutation.)}

Putting const on argc and argv wouldn't buy much, and it would invalidate some old-school programming practices, such as:

// print out all the arguments:
while (--argc)
    std::cout << *++argv << std::endl;

I've written such programs in C, and I know I'm not alone. I copied the example from somewhere.

Eric

-1 Re "Some UNIX APIs, such as getopt, actually do manipulate argv[], so it can't be made const for that reason also.". One can freely add a top-level const to argv, without affecting what any C function can do. Also, getopt is declared as int getopt(int argc, char * const argv[], const char *optstring);. And here the const is not top level, but declares the pointers to be const, a promise to not modify them (although the strings that they point to might conceivably be modified). – Thorlay

@Cheersandhth.-Alf : getopt permutes the argv[] array by default, but does not modify the strings. (The word permute comes directly from the man page.) That means that the argv array itself is not const even if the strings it points to are. How is permuting the argv[] array not manipulating it? – Eric

@Cheersandhth.-Alf : I don't understand the -1. The statement you highlighted was not inaccurate. getopt modifies the argv[] array passed to main. Sure, you can add some amount of const-ness to argv[] and not run afoul of getopt, but the array itself is not const and cannot be const. Storage passed to main and then to getopt gets mutated by getopt, which is all I said. – Eric

@Cheersandhth.-Alf : BTW, you misunderstand the getopt prototype: getopt can write whatever it likes to the argv array. It promises not to modify the characters pointed to by the pointers stored in the argv array. ie. getopt can do argv[0] = "42"; but it can't do argv[0][0] = '4';. – Eric

@Cheersandhth.-Alf : It's interesting... I looked up the prototype in the header, and it has char* const* ___argv there, but the interface actually adheres to const char **. Such confusion. I had confused the precedence of the [] and the * with respect to the const. My apologies. – Eric

@Joe Z, since you're already incrementing argv, why not: while (++argv) cout << *argv << std::endl; – Nimiety

@Alex: I suppose you could; it was just an example, and not intended to be exhaustive. – Eric

FYI: The GNU getopt() knows it does not follow the standard because it pays attention to the POSIXLY_CORRECT environment variable to make it behave correctly. In particular, POSIX does not permute the arguments, and does not look for options after the first non-option argument. – Duodenitis

Answer 2

The C standard (ISO/IEC 9899:2011) says:

5.1.2.2.1 Program startup

¶1 The function called at program startup is named main. The implementation declares no prototype for this function. It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent;¹⁰⁾ or in some other implementation-defined manner.

¶2 If they are declared, the parameters to the main function shall obey the following constraints:

• The value of argc shall be nonnegative.
• 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 startup. The intent is to supply to the program information determined prior to program startup from elsewhere in the hosted environment. If the host environment is not capable of supplying strings with letters in both uppercase and lowercase, the implementation shall ensure that the strings are received in lowercase.
• 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.
• The parameters argc and argv and the strings pointed to by the argv array shall be modifiable by the program, and retain their last-stored values between program startup and program termination.

¹⁰⁾ Thus, int can be replaced by a typedef name defined as int, or the type of argv can be written as char **argv, and so on.

Note the last bullet point. It says that both argc and argv should be modifiable. They don't have to be modified, but they may be modified.

Duodenitis

Interesting. On a semi-related note, I ran into a crash-causing bug that turned out to be because Qt's QApplication(argc,argv) constructor was defined with argc by reference. That surprised me. – Rosaleerosaleen

Answer 3

argc is not normally a constant because the function signature for main() pre-dates const.

Since argc is a stack variable, changing it won't affect anything other than your own command line processing.

You are, of course, free to declare it const if you want.

Disqualify

Answer 4

A top level const on a formal argument is not part of the function type. You can add it or remove it as you like: it only affects what you can do with the argument in the function implementation.

So for argc you can add freely add a const.

But for argv you can not make the character data const without thereby changing the function signature. Which means that it's then not one of the standard main function signatures, and will not have to be recognized as a main function. So, not a good idea.

---

A good reason for not using the standard main arguments in non-toy programs is that in Windows they are not able to represent actual program arguments such as filenames with international characters. That's because in Windows they are by very strong convention encoded as Windows ANSI. In Windows you can implement some more portable argument access facility in terms of the GetCommandLine API function.

---

Summing up, nothing prevents you from adding const to argc, but the most useful const-ness on argv would give you a non-standard main function, most probably not recognized as such. Happily (in an ironic way) there are good reason to not use the standard main arguments for portable serious code. Quite simply, for the in-practice they only support old ASCII, with only English alphabet letters.

Thorlay

If you're developing for Windows with cygwin or another libc that properly supports UTF-8 (as far as I know, cygwin is the only one at present but I have someone working on another option), the standard main signature works fine and you can receive arbitrary Unicode arguments. – Sohn

@R they also work fine on most *nix platforms. the issue is not whether there are platforms where they work. but, very nice initiative, and as it happens i'm doing the same, more or less seriously – Thorlay

As of Windows Version 1903 (May 2019 Update), you can set an applications manifest to use the UTF-8 ActiveCodePage property so that it behaves the same as *nix based platforms in regard to 8 bit text. If you do this you don't need to use any of the Windows specific 16 bit 'W' functions to handle unicode. – Panel

Answer 5

The signature of main is somewhat of a historical artifact from C. Historically C did not have const.

However, you can declare your parameter const since the effects of const are compile time only.

Woodsum

When you say "historical C" how historical are we talking here? – Eric

const was added to C89/C90; prior to that, it was not part of C. – Duodenitis

@JonathanLeffler : You know, I had forgotten that. I learned C in 1992. Prior to that I was a Pascal, BASIC and assembly hacker. – Eric

Answer 6

Because argc is a local variable (and, in C++, not a reference or something), and because the special place of main means that backwards compatibility shenanigans grant it a huge amount of leeway with no compelling reason to force applications to make it const.

main() {}

int main() {}

main() { return 0; }

main(int argc, char* argv[]) { return 0; }

int main(const int argc, const char** argv) { /* no return*/ }

these and many other variations will compile on a wide range of C and C++ compilers.

So ultimately it's not that argc isn't const, just that it doesn't have to be, but it can be if you want it to be.

http://ideone.com/FKldHF, C example:

main(const int argc, const char* argv[]) { return 0; }

http://ideone.com/m1qc9c, C++ example

main(const int argc) {}

Fortis

Note that the variants without an explicit return type are no longer valid in C99, let alone C11, though compilers continue to allow them for reasons of backwards compatibility. C++ compilers should not accept the variants without a return type. – Duodenitis

@JonathanLeffler Yep, yet the last ideone example there (ideone.com/m1qc9c) is G++ 4.8.2 with -std=c++11. Clang also accepts it but does give warning: only one parameter on 'main' declaration [-Wmain], and MSVC only protests about the missing return type specifier and lack of a reference to argc. Again, 'shenanigans' and 'leeway' :) – Fortis

Answer 7

Aside from the historical reasons, a good reason to keep argc and argv non-const is that the compiler implementation doesn't know what you're going to do with the arguments to main, it just knows that it must give you those arguments.

When you are defining your own functions and associated prototypes, you know which parameters you can make const and which ones your function will modify.

Taken to an extreme, you could declare that all parameters to all functions should be declared const, and then if you had a reason to change them (e.g. decrement an index to search through an array), you'd have to make local non-const variables and copy the const arguments' values into those variables. That makes for busy-work and extra LOC with no real benefit. A decent static analyzer will pick up if you're not modifying the value of an argument, and recommend that you make the parameter const.

Hoopen