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?

--
Martin

[Keith Thompson]

Re: Why is argv not pointing to const?

Martin <martindotunder scoreobrien@whi ch.tnetwrites:

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?

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Martin]

Re: Why is argv not pointing to const?

On Sat, 01 Mar 2008 21:43:34 -0000, Keith Thompson <kst-u@mib.orgwrote:

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.

--
Martin

[Keith Thompson]

Re: Why is argv not pointing to const?

Martin <martindotunder scoreobrien@whi ch.tnetwrites:

On Sat, 01 Mar 2008 21:43:34 -0000, Keith Thompson <kst-u@mib.orgwrote:

>Probably lint (note that there are a number of lint
>implementation s) 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.

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.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Re: Why is argv not pointing to const?

Keith Thompson wrote:

Martin <martindotunder scoreobrien@whi ch.tnetwrites:

>On Sat, 01 Mar 2008 21:43:34 -0000, Keith Thompson <kst-u@mib.orgwrote:

>>Probably lint (note that there are a number of lint
>>implementatio ns) 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.

>
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

--
Eric Sosman
esosman@ieee-dot-org.invalid

[Martin]

Re: Why is argv not pointing to const?

My thanks Keith and Eric. I've just looked at the C89 Standard
<http://flash-gordon.me.uk/ansi.c.txtand 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

--
Martin

[CBFalconer]

Re: Why is argv not pointing to const?

Martin wrote:

>
My thanks Keith and Eric. I've just looked at the C89 Standard
<http://flash-gordon.me.uk/ansi.c.txtand 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

[Martin]

Re: Why is argv not pointing to const?

On Mon, 03 Mar 2008 22:35:08 -0000, CBFalconer <cbfalconer@yah oo.com>
wrote:

Martin wrote:

>>
>My thanks Keith and Eric. I've just looked at the C89 Standard
><http://flash-gordon.me.uk/ansi.c.txtand 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.

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

--
Martin