modifying the strings pointed to by argv

[subramanian100in]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

 

[Richard Heathfield]

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

What can be the maximum length of such a string that is copied ?

0, if you have lots of sense. If you have only a little sense, then find
out how long the existing string is, and don't exceed that value. If
you have no sense whatsoever, pay no attention to either of the above
suggestions.

 

[Bryan]

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

Well, possibly, but there's no particularly good reason I can see for
the arguments passed to your function to be read-only. It could
potentially be useful to space-trim or similar the input arguments and
certainly there's at least one (admittedly sub-optimal) unix[1] hack
involving modifying the argv[] values so that program arguments do not
appear in the ps process listing.

Can you clear up why you think this functionality is unwise ?


[1] Granted, slightly off-topic here, but then again there's a good
few things in the C standard that are that way to avoid breaking how
existng code works, so I'd like to apply for a temporary on-topic
licence for this discussion.

 

[Cong Wang]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

Well. There is still something to be clarify.

The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.

The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char buf[2] = {0};
strcpy(argv[1], buf);
return 0;
}

I guess making that modifiable may be considered for exec*() functions
or for the recursion of main(). And the maximum length maybe found in
POSIX.

 

[subramanian100in]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

Well. There is still something to be clarify.

The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.

The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
        char buf[2] = {0};
        strcpy(argv[1], buf);
        return 0;

}

I guess making that modifiable may be considered for exec*() functions
or for the recursion of main(). And the maximum length maybe found in
POSIX.

No. in VC++ 2005 Express Edition, it allows us to copy, say, "test
message" onto argv[0] itself. Prior to modification argv[0] happened
to be the execautable name. Anyway, I just asked this question for
learning purpose.

 

[Cong Wang]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

Well. There is still something to be clarify.

The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.

The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
        char buf[2] = {0};
        strcpy(argv[1], buf);
        return 0;

}

I guess making that modifiable may be considered for exec*() functions
or for the recursion of main(). And the maximum length maybe found in
POSIX.

No. in VC++ 2005 Express Edition, it allows us to copy, say, "test
message" onto argv[0] itself. Prior to modification argv[0] happened
to be the execautable name. Anyway, I just asked this question for
learning purpose.

No for what?

Copying "test message" onto argv[0] is _not_ modifying argv[0] itself,
only changing the contents of the array which argv[0] points to.
What's more, copying to argv[0] is UB.

 

[subramanian100in]

On Mar 14, 9:09 pm, "(e-mail address removed), India"
The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?
Well. There is still something to be clarify.
The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.
The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
        char buf[2] = {0};
        strcpy(argv[1], buf);
        return 0;
}
I guess making that modifiable may be considered for exec*() functions
or for the recursion of main(). And the maximum length maybe found in
POSIX.

No. in VC++ 2005 Express Edition, it allows us to copy, say, "test
message" onto argv[0] itself. Prior to modification argv[0] happened
to be the execautable name. Anyway, I just asked this question for
learning purpose.

No for what?

Copying "test message" onto argv[0] is _not_ modifying argv[0] itself,
only changing the contents of the array which argv[0] points to.
What's more, copying to argv[0] is UB.- Hide quoted text -

- Show quoted text -

I am sorry. Entire post of mine in this thread is wrong.

 

[Guest]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

Well. There is still something to be clarify.

The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.

This came up on comp.std.c again recently. The intent is that the argv
array itself /is/ required to be modifiable, and the actual wording of
the standard can be argued to require the same.

 

[J. J. Farrell]

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

As with many aspects of Standard C it was to support common pre-
existing practice. In UNIXes of the time the ps command could be used
to view the current argv data. Programs made use of this facility
either to hide the parameters they were invoked with (for example, if
a password was passed as a command line option) or to make application
status information available through ps (sendmail did this if I
remember correctly). I don't know if modern UNIXes and similar still
use this.

 

[CBFalconer]

.... snip ...

The standard just says "argc and argv and the strings pointed to
by the argv array shall be modiï¬able by the program." But the
argv array _itself_ is _not_ required to be modiï¬able.

^^^
I fail to understand why this char-set cannot include the normal
coding for 'f' and 'i', thus causing abnormal displays.

The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
char buf[2] = {0};
strcpy(argv[1], buf);
return 0;
}

I guess making that modifiable may be considered for exec*()
functions or for the recursion of main(). And the maximum length
maybe found in POSIX.

There are _no_ restrictions against modifying argv and argc. After
all, those are values local to main. The only restrictions are
against modifying *argv (forbidden) and *argv (for i <= argc),
which is not allowed to extend the length of the string argv.
So this has nothing to do with any possible recursive call to main.

 

[CBFalconer]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?
What can be the maximum length of such a string that is copied ?

Well. There is still something to be clarify.

The standard just says "argc and argv and the strings pointed to by
the argv array shall be modiï¬able by the program." But the argv array
_itself_ is _not_ required to be modiï¬able.

The following buggy code only works well when argc >=2 and
strlen(argv[1]) >=1:

#include <stdio.h>
#include <string.h>

int main(int argc, char *argv[])
{
    char buf[2] = {0};
    strcpy(argv[1], buf);
    return 0;

}

I guess making that modifiable may be considered for exec*() functions
or for the recursion of main(). And the maximum length maybe found in
POSIX.

No. in VC++ 2005 Express Edition, it allows us to copy, say, "test
message" onto argv[0] itself. Prior to modification argv[0] happened
to be the execautable name. Anyway, I just asked this question for
learning purpose.

VC is a specific implementation, and has nothing to do with
validity of the operation. In fact there is a large probability
that the above action contravenes the standard. It depends on the
actual values of argc (> 0) and argv (non-NULL, with
strlen(argv[0]) >= strlen("test message")). Modifying the actual
value of argv[0] (a pointer) is not allowed.

 

[Richard Heathfield]

Bryan said:

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1],
etc. Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

Well, possibly, but there's no particularly good reason I can see for
the arguments passed to your function to be read-only.

Can you give me a particularly good reason for modifying them? I can
think of none. Oh, wait a minute...

It could
potentially be useful to space-trim or similar the input arguments and
certainly there's at least one (admittedly sub-optimal) unix[1] hack
involving modifying the argv[] values so that program arguments do not
appear in the ps process listing.

....still struggling to see a /good/ reason. The ps thing is beyond the
scope of this discussion. This strikes me as a shell issue rather than
an argv issue. But as for space-trimming the input arguments, why not
leave them in peace and just copy out the bits you need?

Can you clear up why you think this functionality is unwise ?

I consider it to be unwarranted chumminess with the start-up code.

 

[Guest]

Bryan said:

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1],
etc. Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

Well, possibly, but there's no particularly good reason I can see for
the arguments passed to your function to be read-only.

Can you give me a particularly good reason for modifying them?

An extended getopt function. If a program is called as './program a -r
b' and -r is to be considered an option, the function (with an already
standardised interface) needs to make sure that after the options are
read, argv[2] points to "a", and argv[3] points to "b", so that the
rest of the program can simply process all non-option arguments one by
one up to the last.

 

[Richard Tobin]

Well, possibly, but there's no particularly good reason I can see for
the arguments passed to your function to be read-only.

[/QUOTE]

Can you give me a particularly good reason for modifying them? I can
think of none. Oh, wait a minute...

It could
potentially be useful to space-trim or similar the input arguments and
certainly there's at least one (admittedly sub-optimal) unix[1] hack
involving modifying the argv[] values so that program arguments do not
appear in the ps process listing.

...still struggling to see a /good/ reason.

Another use on some systems is to cause ps-like programs to display
some useful status information about the running program.

-- Richard

 

[Default User]

Bryan said:

Can you give me a particularly good reason for modifying them? I can
think of none.

One thing that comes to mind is that you could pass the arg strings to
strtok() without having to make a copy. I don't know that this
qualifies as a good reason, but it's possibly a reason for requiring
that.

I've never personally run across a "use case".




Brian

 

[Mark McIntyre]

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?

To save you having to create a copy. Remember, C was written for a
machine with a _very_ small amount of memory by today's standards.

What can be the maximum length of such a string that is copied ?

Naturally, you can't copy anything larger than the original length of
the the argument.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

^^^
I fail to understand why this char-set cannot include the normal
coding for 'f' and 'i', thus causing abnormal displays.

[...]

It's a ligature. In typesettings, it's common for certain pairs of
letters, such as "fl" or "fi", to be joined into a single glyph.

The "fi" in "modifiable" appears as a ligature in my copy of
n1124.pdf, but as two separate letters when I copy-and-paste it. I've
had problems in the past with copy-and-pasting ligatures but I can't
reproduce it at the moment.

See <http://en.wikipedia.org/wiki/Typographical_ligature> for more
information on ligatures. (I'm assuming the article is accurate; if
it isn't, it's good enough to fool me.)

 

[Racaille]

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1], etc.
Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

Why ? Just because you don't like it ?

And any reason you may give why assume that program arguments are
'naturally'
read-only is off-topic here, since they are part of the OS/shell
interface.

 

[Richard Heathfield]

Racaille said:

(e-mail address removed), India said:

The standard allows that we can copy strings onto arg[0], arg[1],
etc. Why is it allowed ?

Good question. Why indeed? It's a stupid stupid stupid idea, if ever
there was one.

Why ? Just because you don't like it ?

I have this innate tendency not to like stupid ideas (except, perhaps,
democracy, for which I retain a certain fondness).

And any reason you may give why assume that program arguments are
'naturally' read-only is off-topic here, since they are part of the
OS/shell interface.

What on earth are you smoking? Of course the nature of main()'s
arguments is topical here!

 

[Racaille]

I have this innate tendency not to like stupid ideas (except, perhaps,
democracy, for which I retain a certain fondness).

I don't care about your mildly conservative opinions about democracy.
(In fact, I find them insulting, but this is off-topic here).

What on earth are you smoking? Of course the nature of main()'s
arguments is topical here!

Please a) be polite b) explain what you understand by the 'nature' of
main()'s arguments. 'char **argv' is not different from 'char **foo',
and
the way the OS, dynamic linker, etc manages to call main() and to
construct its argument list is not specified by any standard.