473,320 Members | 2,145 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Is it OK to modify argv ???

I'm working on a program which has a "tree" of command line arguments,
i.e.,
myprogram level1 [ level2 [ level3 ...]]]
such that there can be more than one level2 argument for each level1
argument and more than one level3 argument for each level2 argument, etc.

Suppose I code it similar to this fragment:

int main( int argc, char *argv[] )
{
...
if ( strcmp(argv[1], "blivet") == 0 )
return do_blivet( --argc, ++argv );
else if ( ...
...
}

int do_blivet( int argc, char *argv[] ) {
...
if ( strcmp(argv[1], "whosis") == 0 )
return do_whosis( --argc, ++argv );
else if ( ...
...
}

It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?
I'm wondering whether doing this might prevent memory
allocated for array *argv[] from being freed upon program exit,
under some operating systems.

Thanks for your advice.

Regards,
Charles Sullivan

Nov 13 '05 #1
28 12412

Charles Sullivan <cw******@triad.rr.com> wrote in message
news:pa*************************@triad.rr.com...
I'm working on a program which has a "tree" of command line arguments,
i.e.,
myprogram level1 [ level2 [ level3 ...]]]
such that there can be more than one level2 argument for each level1
argument and more than one level3 argument for each level2 argument, etc.

Suppose I code it similar to this fragment:

int main( int argc, char *argv[] )
{
...
if ( strcmp(argv[1], "blivet") == 0 )
return do_blivet( --argc, ++argv );
else if ( ...
...
}

int do_blivet( int argc, char *argv[] ) {
...
if ( strcmp(argv[1], "whosis") == 0 )
return do_whosis( --argc, ++argv );
else if ( ...
...
}

It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?
I'm wondering whether doing this might prevent memory
allocated for array *argv[] from being freed upon program exit,
under some operating systems.

Thanks for your advice.


Remember that C arguments are passed 'by value'.
So any changes you make to a function's parameters
will not be reflected by the caller. 'main()' is
no different from any other function in this respect.

-Mike

Nov 13 '05 #2
Charles Sullivan wrote:
I'm working on a program which has a "tree" of command line arguments,
int main(int argc, char **argv)
{
it's okay to modify argv, because it's just a copy of a pointer.

argv++; /* no problem here */

it's okay to modify argv[i][n], provided such a character exists. Thus:

if(strlen(argv[1]) > strlen("hello")
{
strcpy(argv[1], "hello"); /* no problem here */
}

it's NOT okay to modify the pointer argv[i]:

argv[i] = "new pointer value"; /* BUG! */

It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?
Yes, that's fine.
I'm wondering whether doing this might prevent memory
allocated for array *argv[] from being freed upon program exit,
under some operating systems.


As long as you stick to the rules I outlined above (and all the other rules,
and some more that I haven't thought of yet), you'll be fine.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #3
Charles Sullivan <cw******@triad.rr.com> wrote:

<SNIP>

int do_blivet( int argc, char *argv[] ) {
...
if ( strcmp(argv[1], "whosis") == 0 )
return do_whosis( --argc, ++argv );
else if ( ...
...
}

It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?
I'm wondering whether doing this might prevent memory
allocated for array *argv[] from being freed upon program exit,
under some operating systems.

argc and argv have function scope, IOW they are local to main();
thus, you may arbitrarily change their values without doing harm
to anything that happens to take place outside of main().

Regards,

Irrwahn
--
do not write: void main(...)
do not use gets()
do not cast the return value of malloc()
do not fflush( stdin )
read the c.l.c-faq: http://www.eskimo.com/~scs/C-faq/top.html
Nov 13 '05 #4
Charles Sullivan <cw******@triad.rr.com> wrote:
I'm working on a program which has a "tree" of command line arguments,
i.e.,
myprogram level1 [ level2 [ level3 ...]]]
such that there can be more than one level2 argument for each level1
argument and more than one level3 argument for each level2 argument, etc.

Suppose I code it similar to this fragment:

int main( int argc, char *argv[] )
{
...
if ( strcmp(argv[1], "blivet") == 0 )
return do_blivet( --argc, ++argv );
else if ( ...
...
}

int do_blivet( int argc, char *argv[] ) {
...
if ( strcmp(argv[1], "whosis") == 0 )
return do_whosis( --argc, ++argv );
else if ( ...
...
}

It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?


Yes, it's just a regular function paramater.

- Kevin.
Nov 13 '05 #5

"Charles Sullivan" <cw******@triad.rr.com> wrote in message
It turns out to be somewhat more convenient in practise to increment
argv as above than to pass the argument (argv + 1).

My question: Is it correct C code to increment argv as above?

It is OK. It may not be a good idea. There is a school of thought that
function parameters shouldn't be modified at all by the callee. In a
mathematical function this makes sense, since in mathematical convention the
symbols have constant values.
In the case of argv and argc , a maintaining programmer wouldn't expect
these to be modified, and might wonder why argv[0] no longer pointed to the
program name.
On the other hand, if the code does look a lot clearer with the
modification, then it is quite hard to argue that you shouldn't use it.
Nov 13 '05 #6
>> I'm working on a program which has a "tree" of command line arguments,

int main(int argc, char **argv)
{
it's okay to modify argv[i][n], provided such a character exists. Thus:

if(strlen(argv[1]) > strlen("hello")
{
strcpy(argv[1], "hello"); /* no problem here */
}
it's NOT okay to modify the pointer argv[i]:

argv[i] = "new pointer value"; /* BUG! */


Why that? argv[n] is just a copy too, that is, argv and argv[*] are within the
stack, and even argv[*][*] is.

--
- Jan Engelhardt
Nov 13 '05 #7
Jan Engelhardt <je*****@linux01.gwdg.de> wrote:
I'm working on a program which has a "tree" of command line arguments,


int main(int argc, char **argv)
{
it's okay to modify argv[i][n], provided such a character exists. Thus:

if(strlen(argv[1]) > strlen("hello")
{
strcpy(argv[1], "hello"); /* no problem here */
}

it's NOT okay to modify the pointer argv[i]:

argv[i] = "new pointer value"; /* BUG! */


Why that? argv[n] is just a copy too, that is, argv and argv[*] are within the
stack, and even argv[*][*] is.


Errm..., could you please elaborate on this?

Hint: Where does argv point to?

BTW: There's nothing like a stack from the C POV.

Regards

Irrwahn
--
do not write: void main(...)
do not use gets()
do not cast the return value of malloc()
do not fflush( stdin )
read the c.l.c-faq: http://www.eskimo.com/~scs/C-faq/top.html
Nov 13 '05 #8
Jan Engelhardt wrote:
I'm working on a program which has a "tree" of command line arguments,
int main(int argc, char **argv)
{
it's okay to modify argv[i][n], provided such a character exists. Thus:

if(strlen(argv[1]) > strlen("hello")
{
strcpy(argv[1], "hello"); /* no problem here */
}

it's NOT okay to modify the pointer argv[i]:

argv[i] = "new pointer value"; /* BUG! */


Why that? argv[n] is just a copy too,


Wrong. Consider the following code:

#include <stdlib.h>
int foo(char **v)
{
char *p = "Hello";
v[0] = p;
}
int main(void)
{
char *v[1] = {0};
v[0] = malloc(10);
if(v[0] != NULL)
{
foo(v);
free(v[0]); /* bang! */
}
return 0;
}
that is, argv and argv[*] are within
the stack, and even argv[*][*] is.


The Standard says:

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.

Since nothing is said about the pointers themselves, we must assume they are
non-modifiable.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #9
Richard Heathfield wrote:
The Standard says:

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.

Since nothing is said about the pointers themselves, we must assume they are
non-modifiable.


Is it non-portable to swap them, though, like getopt() does?

char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?

Nov 13 '05 #10
Matt Gregory wrote:
Richard Heathfield wrote:
The Standard says:

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.

Since nothing is said about the pointers themselves, we must assume they
are non-modifiable.


Is it non-portable to swap them, though, like getopt() does?

char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?


Undefined behaviour, IMHO, for the reason stated above. Of course, I'm ready
to be corrected by anyone with appropriate C&V.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #11
Thanks folks. You've answered my question and also helped clarify my
thinking.

Much appreciated!

Regards,
Charles Sullivan
Nov 13 '05 #12
On Sat, 13 Sep 2003 19:01:24 UTC, Irrwahn Grausewitz
<ir*****@freenet.de> wrote:
Jan Engelhardt <je*****@linux01.gwdg.de> wrote:
I'm working on a program which has a "tree" of command line arguments,

int main(int argc, char **argv)
{
it's okay to modify argv[i][n], provided such a character exists. Thus:

if(strlen(argv[1]) > strlen("hello")
{
strcpy(argv[1], "hello"); /* no problem here */
}

it's NOT okay to modify the pointer argv[i]:

argv[i] = "new pointer value"; /* BUG! */


Why that? argv[n] is just a copy too, that is, argv and argv[*] are within the
stack, and even argv[*][*] is.


Errm..., could you please elaborate on this?

Hint: Where does argv point to?


argv points to an array of pointers. It is possible to change one or
all of them.
argv[] points to an zero termitated array of chars. It is possible to
change any char in that array. You may even store any other string
that is equal in size or shorter than the initial one there. Storing a
string that is longer results in undefined behavior.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #13
On Sat, 13 Sep 2003 23:12:44 UTC, Matt Gregory
<ms********@earthlink.net> wrote:
Richard Heathfield wrote:
The Standard says:

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.

Since nothing is said about the pointers themselves, we must assume they are
non-modifiable.

What is argv? It is a pointer to an array of pointers. So any pointer
argv points to is changeable.
Any string a pointer in the array of pointers is changeable too.
Is it non-portable to swap them, though, like getopt() does?

char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?

It is portable. The only you can't do is to insert more pointers as
argc says it has at startup.

At startup argc contains the number of pointers argv points to.
Changing the sequence in the array is ok. Changing any pointer in the
array to whatever is ok too. Adding more pointers as the initial value
has is NOT ok.

Changing an array arv[] poits to is ok. You may shorten this array as
kile. Extending it results in undefined behavior.

argv is in memory the application has unlimited access to (else the
CRT would fail to build it).

argv is nothing than each other pointer to an array of pointers that
points to strings.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #14
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Sat, 13 Sep 2003 19:01:24 UTC, Irrwahn Grausewitz
<ir*****@freenet.de> wrote:
Jan Engelhardt <je*****@linux01.gwdg.de> wrote:
>
> Richard Heathfield wrote:
>>
>> it's NOT okay to modify the pointer argv[i]:
>>
>> argv[i] = "new pointer value"; /* BUG! */
>
>Why that? argv[n] is just a copy too, that is, argv and argv[*] are within the
>stack, and even argv[*][*] is.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Errm..., could you please elaborate on this?

Hint: Where does argv point to?


argv points to an array of pointers. It is possible to change one or
all of them.
argv[] points to an zero termitated array of chars. It is possible to
change any char in that array. You may even store any other string
that is equal in size or shorter than the initial one there. Storing a
string that is longer results in undefined behavior.


This discussion was not about changing the /characters/ pointed to, it
was about changing the /pointer/ values. And JE's claim that argv[n]
is a local copy of a pointer (just like argv, which undoubtely is), is
plain wrong.

Irrwahn
--
Proofread carefully to see if you any words out.
Nov 13 '05 #15
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Sat, 13 Sep 2003 23:12:44 UTC, Matt Gregory
<ms********@earthlink.net> wrote:
Richard Heathfield wrote:
> The Standard says:
>
> 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.
>
> Since nothing is said about the pointers themselves, we must assume they are
> non-modifiable.


What is argv? It is a pointer to an array of pointers. So any pointer
argv points to is changeable.
Any string a pointer in the array of pointers is changeable too.
Is it non-portable to swap them, though, like getopt() does?

char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?

It is portable. The only you can't do is to insert more pointers as
argc says it has at startup.

At startup argc contains the number of pointers argv points to.
Changing the sequence in the array is ok. Changing any pointer in the
array to whatever is ok too.


To whatever? So you consider the last line of the following code that
Richard posted upthread to be correct (comment delimiters deliberately
added)?

RH> int main(int argc, char **argv)
RH> {
RH> /* it's okay to modify argv, because it's just a copy of a
RH> pointer.*/
RH>
RH> argv++; /* no problem here */
RH>
RH> /* it's okay to modify argv[i][n], provided such a character
RH> exists. Thus:*/
RH>
RH> if(strlen(argv[1]) > strlen("hello")
RH> {
RH> strcpy(argv[1], "hello"); /* no problem here */
RH> }
RH>
RH> /* it's NOT okay to modify the pointer argv[i]: */
RH>
RH> argv[i] = "new pointer value"; /* BUG! */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the interesting line.

Irrwahn
--
Close your eyes and press escape three times.
Nov 13 '05 #16
The Real OS/2 Guy wrote:
On Sat, 13 Sep 2003 23:12:44 UTC, Matt Gregory
<ms********@earthlink.net> wrote:
char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?

It is portable.


I disagree. The standard gives explicit permission to modify argv itself and
the strings pointed to by argv[0] through argv[argc - 1], but it doesn't
give permission to modify argv[0] through argv[argc - 1] themselves.

If you can provide C&V to back up your point of view, please do so.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #17
On Sun, 14 Sep 2003 14:57:11 UTC, Irrwahn Grausewitz
<ir*****@freenet.de> wrote:

To whatever? So you consider the last line of the following code that
Richard posted upthread to be correct (comment delimiters deliberately
added)?
RH> /* it's NOT okay to modify the pointer argv[i]: */
RH>
RH> argv[i] = "new pointer value"; /* BUG! */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the interesting line.

Yes - so long i is < argc and he has either saved the string argv[i]
points to before or has really no interest on the parameter he's
loosing now.

--
Tschau/Bye
Herbert

eComStation 1.1 Deutsch Beta ist verügbar
Nov 13 '05 #18
"The Real OS/2 Guy" <os****@pc-rosenau.de> wrote:
On Sun, 14 Sep 2003 14:57:11 UTC, Irrwahn Grausewitz
<ir*****@freenet.de> wrote:

To whatever? So you consider the last line of the following code that
Richard posted upthread to be correct (comment delimiters deliberately
added)?
RH> /* it's NOT okay to modify the pointer argv[i]: */
RH>
RH> argv[i] = "new pointer value"; /* BUG! */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the interesting line.

Yes - so long i is < argc and he has either saved the string argv[i]
points to before or has really no interest on the parameter he's
loosing now.


Which part of the standard makes you think so? Chapter and verse,
please.
--
Close your eyes and press escape three times.
Nov 13 '05 #19

On Sun, 14 Sep 2003, The Real OS/2 Guy wrote:

On Sun, 14 Sep 2003 14:57:11 UTC, Irrwahn Grausewitz wrote:

To whatever? So you consider the last line of the following code that
Richard posted upthread to be correct (comment delimiters deliberately
added)?

RH> /* it's NOT okay to modify the pointer argv[i]: */
RH>
RH> argv[i] = "new pointer value"; /* BUG! */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the interesting line.


Yes - so long i is < argc and he has either saved the string argv[i]
points to before or has really no interest on the parameter he's
loosing now.

% cat last-message
To whatever? So you consider the last line of the following code that
Richard posted upthread to be correct (comment delimiters deliberately
added)?
% /imaginary/bin/remove-rhetoric < last-message
So you're wrong, obviously. Consult the Standard. argv[i] is
not modifiable. Period. End of discussion.


%
-Arthur
Nov 13 '05 #20
Richard Heathfield wrote:
The standard gives explicit permission to modify argv itself and
the strings pointed to by argv[0] through argv[argc - 1], but it doesn't
give permission to modify argv[0] through argv[argc - 1] themselves.


Strange that you can modify the strings, considering that they may
in fact be null strings. How can you modify a null string?

I would have found it more reasonable that you would have to leave the
original strings alone, but have the freedom to allocate and substitute
different strings in the argv array, or in fact allocate a new argv structure
and change argv to point to the new one.

On rereading the Standard (from 5.1.2.2.1 Program startup)

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.

I can imagine that that means my alternative interpretation without too much stretch.

It might mean not that the content of the original strings are modifiable, but
that the strings themselves can be substituted for other strings.

Where are the examples? The Standard should be overflowing with examples
of code that reinforce what the prose text says.

- Larry Weiss
Nov 13 '05 #21


Richard Heathfield wrote:
The Real OS/2 Guy wrote:

On Sat, 13 Sep 2003 23:12:44 UTC, Matt Gregory
<ms********@earthlink.net> wrote:

char *temp = argv[2];
argv[2] = argv[1];
argv[1] = temp;

What's the story on that?


It is portable.

I disagree. The standard gives explicit permission to modify argv itself and
the strings pointed to by argv[0] through argv[argc - 1], but it doesn't
give permission to modify argv[0] through argv[argc - 1] themselves.

Here is what the standard says:

"
_
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.
"

This might be interpeted as as argv and its parameters,
argv[0] (program name), and argv[1] through argv[argc-1]
collectively called program parameters, are modifiable.

My opinion is that is only safe to modify argv in the
matter of k&r.
while(--argc > 0)
{
printf("%s%s", *++argv, (argc>1)?" ":"");
printf("\n");
}

I have never felt it safe to modify by enlarging the strings
pointed to by argv nor modify argv[0] thru argv[argc].

--
Al Bowers
Tampa, Fl USA
mailto: xa*@abowers.combase.com (remove the x)
http://www.geocities.com/abowers822/

Nov 13 '05 #22
Al Bowers wrote:

<snip>
This might be interpeted as as argv and its parameters,
argv[0] (program name), and argv[1] through argv[argc-1]
collectively called program parameters, are modifiable.

No, it explicitly names the argv object itself, and the strings pointed to
by the argv array. It says nothing about the members of the argv array
themselves.
My opinion is that is only safe to modify argv in the
matter of k&r.
while(--argc > 0)
{
printf("%s%s", *++argv, (argc>1)?" ":"");
printf("\n");
}

I have never felt it safe to modify by enlarging the strings
pointed to by argv nor modify argv[0] thru argv[argc].


On the enlarging-strings side, neither have I. In fact, I don't believe
there's a guaranteed-safe way to do this. I think you're okay with argv[0]
though.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #23
Richard Heathfield wrote:
On the enlarging-strings side, neither have I. In fact, I don't believe
there's a guaranteed-safe way to do this. I think you're okay with argv[0]
though.


Again, I'll say that if the authors of the C Standard would take the time
to create and publish some actual examples, then we all could be much more
assured in what we "think" we know about C.

- Larry Weiss
Nov 13 '05 #24
On Sun, 14 Sep 2003 21:13:39 -0500, Larry__Weiss <lf*@airmail.net>
wrote:
Richard Heathfield wrote:
The standard gives explicit permission to modify argv itself and
the strings pointed to by argv[0] through argv[argc - 1], but it doesn't
give permission to modify argv[0] through argv[argc - 1] themselves.

Strange that you can modify the strings, considering that they may
in fact be null strings. How can you modify a null string?

A null string is an array (or sequence) of 1 char containing '\0'.
You can store any char value there, although if nonzero the result can
no longer be used as a string. This isn't terribly useful, in fact
it's probably not useful at all, but it is well-defined and legal.
I would have found it more reasonable that you would have to leave the
original strings alone, but have the freedom to allocate and substitute
different strings in the argv array, or in fact allocate a new argv structure
and change argv to point to the new one.
Being able to change argv to point to a different array, allocated or
not, follows from the required passing of arguments by value -- unless
main is special -- so I would absolutely expect that. Beyond that, I
don't see why it should be more or less reasonable to change the
pointers in argv[i] versus the string contents they point to. In
practice, on every implementation I know of, both of those are in fact
modifiable, and I can't come up with a plausible way they wouldn't,
but the Standard guarantees only the latter not the former.

The only rationale I have to hand, n937, says nothing relevant. At a
wild guess, I suspect it might be because by the time of C89 some Unix
programs (arguably too many, but that's a different issue) did clobber
some or all of their arg string contents as a way to fiddle their
display by 'ps', but that didn't require changing the string pointers
and AFAIK none did.
On rereading the Standard (from 5.1.2.2.1 Program startup)

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.

I can imagine that that means my alternative interpretation without too much stretch.

It might mean not that the content of the original strings are modifiable, but
that the strings themselves can be substituted for other strings.
I can't (imagine that). It says "the strings pointed to by the argv
array", although to be absolutely clear it probably should say "by the
elements of the array the first element of which argv points to" or
simpler just repeat the earlier usage "by argv[0] to argv[argc-1]",
and "string" is defined in 7.1.1 as "a contiguous sequence of
characters terminated by and including the first null character.".
It isn't explicitly stated, but is clear throughout, this sequence is
actually (in) an array of char. Or alternatively, is in an object,
all of whose bytes are char values and thus can be accessed as array
of char. Given those, I don't think you can read 5.1.2.2.1 as
referring to the string pointers rather than their contents.

In particular, C programmers often talk loosely about a (qualified)
char* as "being" a string, but AFAIHS the Standard never does, it
consistently says "points to" or conversely "pointed to by".
Where are the examples? The Standard should be overflowing with examples
of code that reinforce what the prose text says.

554 pages isn't enough for you? You want 2,000? How many examples
would it take to fully cover all possibilities just for valid and
invalid usage of main's arguments? 5? 10? 20? 100?

And when mistakes are made and the examples disagree -- as some surely
will -- you won't be able to trust them anyway. I think there's too
many examples already; it makes it harder to search for some terms.
(But I'm not asking for anyone to go to the work of removing them, at
least not unless they are found to be defective.)

- David.Thompson1 at worldnet.att.net
Nov 13 '05 #25
Dave Thompson wrote:
On Sun, 14 Sep 2003 21:13:39 -0500, Larry__Weiss <lf*@airmail.net>
wrote:
Where are the examples? The Standard should be overflowing with examples
of code that reinforce what the prose text says.

554 pages isn't enough for you? You want 2,000? How many examples
would it take to fully cover all possibilities just for valid and
invalid usage of main's arguments? 5? 10? 20? 100?

And when mistakes are made and the examples disagree -- as some surely
will -- you won't be able to trust them anyway. I think there's too
many examples already; it makes it harder to search for some terms.
(But I'm not asking for anyone to go to the work of removing them, at
least not unless they are found to be defective.)


Incorrect examples can be corrected, and the process of correcting them
itself would be a illuminating event lending understanding to the correct
interpretation of the text of the Standard.

Correctly constructed examples can only serve to reinforce the text
of the Standard. Perhaps they need their own section of the Standard.
I too find that the examples that exist in the midst of the Standard text
(primarily as footnotes) are not always the best use of the typographical
space within the Standard document itself.

I don't want the examples to be normative, but I do want the examples
to be refereed by the same process as any other text of the Standard.
Nov 13 '05 #26
Richard Heathfield wrote:
On the enlarging-strings side, neither have I. In fact, I don't believe
there's a guaranteed-safe way to do this. I think you're okay with argv[0]
though.


An amazing amount of uncertainty in such a simple matter!

- Larry Weiss
Nov 13 '05 #27
Larry__Weiss wrote:

Richard Heathfield wrote:
On the enlarging-strings side, neither have I. In fact, I don't believe
there's a guaranteed-safe way to do this. I think you're okay with argv[0]
though.


An amazing amount of uncertainty in such a simple matter!

Simple indeed. argv points to an array of argc+1 pointers to char. Each
of these pointers points to a string of length 0 or more. All is
apparently technically modifiable. The limits of this freedom is not
explained.

One might modify a string by changing certain characters and/or
shortening it. How one might 'add' to it is not described. I'm sure the
array 'char *argv[]' of pointers to char is also modifiable. But what
would you point to?

Such an amazingly simple matter. Not!

--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #28
Joe Wright wrote:
Larry__Weiss wrote:
Richard Heathfield wrote:
On the enlarging-strings side, neither have I. In fact, I don't believe
there's a guaranteed-safe way to do this. I think you're okay with argv[0]
though.


An amazing amount of uncertainty in such a simple matter!

Simple indeed. argv points to an array of argc+1 pointers to char. Each
of these pointers points to a string of length 0 or more. All is
apparently technically modifiable. The limits of this freedom is not
explained.

One might modify a string by changing certain characters and/or
shortening it. How one might 'add' to it is not described. I'm sure the
array 'char *argv[]' of pointers to char is also modifiable. But what
would you point to?

Such an amazingly simple matter. Not!


I'm still not convinced by Richard H.'s reasoning that the Standard is
placing restrictions on the ability to modify the argv structure.

I think it is equally likely that the Standard is just stating some obvious
facts when it states:

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.

There are other obvious facts that it could have listed. Richard finds
significance to that omitted list. I don't.

- Larry Weiss
Nov 13 '05 #29

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Sherman Willden | last post by:
I am trying to use Perl's XML::Twig to modify a version number in an XML document. At the very end of this posting is an excerpt from the xml document. Just before the xml excerpt is the Perl code...
10
by: Robin Sanderson | last post by:
Sorry in advance if this is a stupid question - I am new to C++. In the process of converting program to be run from the command line into a function to be run from another program I noticed...
9
by: mahurshi | last post by:
i have a quick question i am putting a debug flag in my program (i really dont need this feature, but i figured it might be useful when i get into trouble) so i want to check if argv is the...
12
by: Michael B Allen | last post by:
Is it legit to modify static data like the following code? #include <stdlib.h> #include <stdio.h> struct tbl { int i; char *s; };
5
by: jab3 | last post by:
(again :)) Hello everyone. I'll ask this even at risk of being accused of not researching adequately. My question (before longer reasoning) is: How does declaring (or defining, whatever) a...
4
by: interec | last post by:
Hi Folks, I am writing a c++ program on redhat linux using main(int argc, wchar_t *argv). $LANG on console is set to "en_US.UTF-8". g++ compiler version is 3.4.6. Q1. what is the encoding of...
11
by: vicky | last post by:
hi all, please tell me with example, how the *argv point to the the no of strings.
4
by: Romulo Carneiro | last post by:
Hi, I'm programming in Windows XP and i'm trying to get all arguments of some application, but i only have gotten five argv. When i put more then five(5), it didn't display. =>Input Command Line:...
1
by: alireza6485 | last post by:
Hi, I have the following code,it prints out a 5 by 5 matrix and puts "-" in each location. I need to ask user for the number of * they like to put in the matrix and based on the number they enter...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.