Defining main with constant arguments (const int argc, const char * const argv[])?

Question

In glibc, main is documented as either,

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

Or,

int main (int argc, char *argv[], char *envp[])

Can you define all the arguments as being const if you don't want to change them?

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

Is it supported, unsupported, or illegal?

Note that top-level qualifers on function parameter types aren't part of the function declaration, so at least parts of your question aren't relevant. — Kerrek SB
– Kerrek SB, Commented Jun 21, 2018 at 22:55
@KerrekSB not irrelevant because I didn't know that. The question is well defined and if they're not part of the function declaration answer and I'll accept. I get typedef errors when arguments are not declared constant and you send them constant pointers, so I figured it was part of the typing. — Evan Carroll
– Evan Carroll, Commented Jun 21, 2018 at 22:57
Don't get me wrong, top-level constness still matters. Just not for purposes of prototyping, and hence how you're allowed to define main. Also, the const in "const char*" isn't top-level and matters very much. — Kerrek SB
– Kerrek SB, Commented Jun 21, 2018 at 23:01

Kerrek SB · Accepted Answer · 2018-06-21 23:08:49Z

In C, the implementation is allowed to support basically any type for the main function, so it may very well be that your particular implementation allows the various forms you have proposed. (And indeed it seems to allow the three-parameter version that exposes the environment.) However, the implementation is only required to accept the two forms

int main(void)

and

int main(int, char**)

Since int(int, const char**) isn't the same type as int(int, char**), your proposed "constified" version is not strictly speaking required to be supported and falls under the first rule. It is, however, quite likely to work since char* and const char* are laid out the same way as far as the ABI is concerned, and the data you're given is mutable anyway.

Note further that int f(int) and int f(const int) are the same identical prototype, so there is no problem here regarding top-level qualifications of the parameters.

"Note further that int f(int) and int f(const int) are the same identical prototype" - How that? An implementation could used different ways to pass const and non-const parameters. Plase provide references to the standard supporting your claim.
@Olaf: In C, this is achieved via the notion of "compatible types"; all types of declarations of the same thing must be compatible (C11, 6.7p4). For compatibility of function types which includes the non-significance of top-level qualifiers, see 6.7.6.3p15. Demo.
What about 6.7.3p10: "For two qualified types to be compatible, both shall have the identically qualified version of a compatible type". To me this reads like int and const int are not compatible, because hey are not identically qualified. As I pointed out above, this could make sense to allow additional optimisations (not that I have a specific implementation in mind, but SPARC or Hyperstone come to mind). I might not get the point, though, and I just have a problem with my wetware CPU cooler these days.

Collectives™ on Stack Overflow

Defining main with constant arguments (const int argc, const char * const argv[])?

1 Answer 1

3 Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Related