Why is argv not pointing to const?

[Martin]

When referring to the conforming declaration for main, Lint displays

Info 818: Pointer parameter 'argv' (line 3) could be declared as
pointing to const

Presumably it's saying that the definition could be:

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

Why didn't C89 mandate that?

 

[Keith Thompson]

When referring to the conforming declaration for main, Lint displays

Info 818: Pointer parameter 'argv' (line 3) could be declared as
pointing to const

Presumably it's saying that the definition could be:

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

Why didn't C89 mandate that?

Back in 1989, the "const" keyword was new; many pre-ANSI compilers
didn't recognize it, and would have reported a syntax error.
Requiring "const" would have broken existing code.

Note also that the standard specifically requires the parameters argc
and argv, and the strings pointed to by the argv array, to be
modifiable. It's not clear whether the char* elements of the argv
array itself are modifiable; if they are, then requiring "const" here
would break that.

Probably lint (note that there are a number of lint implementations)
is issuing this message because your code didn't happen to modify
these pointers. What happens if you change your function's name from
"main" to something else?

 

[Martin]

Probably lint (note that there are a number of lint
implementations) is issuing this message because
your code didn't happen to modify these pointers.
What happens if you change your function's name
from "main" to something else?

I get the same message from Lint.

I am using PC-lint for C/C++ (NT) Ver. 8.00L, with the options -W -ansi
-pedantic -Wall.

 

[Keith Thompson]

I get the same message from Lint.

I am using PC-lint for C/C++ (NT) Ver. 8.00L, with the options -W
-ansi -pedantic -Wall.

So it looks like PC-lint is recommending that anything that your code
doesn't happen to modify should be declared as const (not bad advice
IMHO), but it's not allowing for the fact that the "main" function is
a special case.

 

[Eric Sosman]

So it looks like PC-lint is recommending that anything that your code
doesn't happen to modify should be declared as const (not bad advice
IMHO), but it's not allowing for the fact that the "main" function is
a special case.

Seems to me that `const' is appropriate only if the
non-modification is part of the "contract" or "interface"
of the function. The fact that today's version of the
function doesn't modify something is not necessarily a
promise that tomorrow's version will do likewise. Take
lint's advice as advice, not as a command.

In fact, that's the way to approach all of lint's
advice. Lint's job is to be a Nervous Nellie, to see a
lurking felon in every shadow and a goblin hiding beneath
every bed. Many of the felons and goblins will turn out
to be imaginary, but it behooves you to shine a few lights
in the shadows and poke under the beds with broomsticks,
just in case. See also the First Commandment at

http://www.lysator.liu.se/c/ten-commandments.html

 

[Martin]

My thanks Keith and Eric. I've just looked at the C89 Standard
<http://flash-gordon.me.uk/ansi.c.txt> and found the key paragraph:

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

 

[CBFalconer]

My thanks Keith and Eric. I've just looked at the C89 Standard
<http://flash-gordon.me.uk/ansi.c.txt> and found the key paragraph:

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

WARNING: do not attempt to lengthen the strings.

 

[Martin]

WARNING: do not attempt to lengthen the strings.

Well, that's certianly worth knowing, but it doesn't seem to be explicit
in the paragraph I quoted.

 

[Keith Thompson]

Well, that's certianly worth knowing, but it doesn't seem to be
explicit in the paragraph I quoted.

It's implicit.

Assume argv[1] points to a string with a length of 10 (and therefore
to an array of at least 11 characters). Attempting to lengthen the
string by copying additional characters into it would write beyond the
bounds of that 11-character array, invoking undefined behavior.

You can very likely get away with assigning a new value to argv[1]
that points to a longer string, but the standard doesn't say that the
char* pointer objects that argv points to are themselves modifiable,
just the argv pointer itself and the strings are modifiable. I don't
know why the modifiability of the char* pointer objects was left out.

(I was slightly imprecise above, but I didn't feel like typing "the
char* pointer objects that are the elements of the array to whose
first element argv points".)