«

"DAGwyn" <> writes:
> The answer to the original question is that of course the elements
> of the array (of length equal to the value of main's int parameter)
> pointed to by main's char** parameter can be modified. If we had
> intended otherwise we would have used const qualification at the
> appropriate position (between the *s) when specifying the interface.

Then why does 5.1.2.2.1p2 explicitly state that the program can modify
argc, argv, and the strings pointed to by the argv array, but not make
the same statement about the elements of the argv array? Was it just
an oversight?

There is precedent (string literals) for making something not
explicitly const, but not allowing it to be modified.

If you're correct, than an implementation that makes argv a pointer to
an array (of char*) in read-only memory (or at least memory that can't
be modified by the program) would be non-conforming, but it's not
quite obvious (to me) from the standard.

And Doug, if you're going to post through Google Groups, please read
<http://cfaj.freeshell.org/google/>. Thanks, and Merry Christmas.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Doug Gwyn writes:
>> The answer to the original question is that of course the elements
>> of the array (of length equal to the value of main's int parameter)
>> pointed to by main's char** parameter can be modified. If we had
>> intended otherwise we would have used const qualification at the
>> appropriate position (between the *s) when specifying the interface.
>

Keith Thompson wrote:
> Then why does 5.1.2.2.1p2 explicitly state that the program can modify
> argc, argv, and the strings pointed to by the argv array, but not make
> the same statement about the elements of the argv array? Was it just
> an oversight?
>
> If you're correct, than an implementation that makes argv a pointer to
> an array (of char*) in read-only memory (or at least memory that can't
> be modified by the program) would be non-conforming, but it's not
> quite obvious (to me) from the standard.
>

FWIW, I submitted a public comment on this issue (Feb 199:
http://david.tribble.com/text/c9xc004.txt

I suggested that since no mention of the argv elements was made,
to add a sentence making it implementation-defined whether they
are modifiable or not.

At the time I submitted the comment, I believe there were systems
that did not allow argv[i] to be modified, and it was not clear that
such systems were or were not conforming.

My comment was rejected, IIRC, because such verbiage was "not
necessary".

-drt

Doug Gwyn writes:
>> The answer to the original question is that of course the elements
>> of the array (of length equal to the value of main's int parameter)
>> pointed to by main's char** parameter can be modified. If we had
>> intended otherwise we would have used const qualification at the
>> appropriate position (between the *s) when specifying the interface.
>

Keith Thompson wrote:
> Then why does 5.1.2.2.1p2 explicitly state that the program can modify
> argc, argv, and the strings pointed to by the argv array, but not make
> the same statement about the elements of the argv array? Was it just
> an oversight?

FWIW, I submitted a public comment about that very issue
(Feb 199:
http://david.tribble.com/text/c9xc004.txt

I suggested that it be deemed implementation-defined whether
or not argv[i] is modifiable. My comment was rejected, IIRC,
because the extra verbiage was not necessary.


> If you're correct, than an implementation that makes argv a pointer to
> an array (of char*) in read-only memory (or at least memory that can't
> be modified by the program) would be non-conforming, but it's not
> quite obvious (to me) from the standard.

At the time I sumbitted my comment, there did exist systems that
did not allow modifying argv[i], and it was not clear whether or not
those systems were conforming.

-drt