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 ?

[CBFalconer]

"su************ **@yahoo.com, India" wrote:

>
On Mar 14, 6:41Â pm, "Cong Wang" <xiyou.wangc... @gmail.comwrote :

On Mar 14, 9:09Â pm, "subramanian10. [e-mail], India"

<subramanian10. [e-mail] te:

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.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Bryan said:

On 14 Mar, 13:19, Richard Heathfield <[e-mail].i nvalidwrote:

>subramanian10. [e-mail], 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Richard Heathfield wrote:

Bryan said:

On 14 Mar, 13:19, Richard Heathfield <[e-mail].i nvalidwrote:

subramanian10.. [e-mail], 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]

In article <Je************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

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

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

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Default User]

Richard Heathfield wrote:

Bryan said:

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.

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]

On 14 Mar 2007 06:09:01 -0700, in comp.lang.c ,
"su************ **@yahoo.com, India" <su************ **@yahoo.com>
wrote:

>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]

CBFalconer <cb********@yah oo.comwrites:

Cong Wang wrote:

>>

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

[...]

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.or g/wiki/Typographical_l igaturefor more
information on ligatures. (I'm assuming the article is accurate; if
it isn't, it's good enough to fool me.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Racaille]

On Mar 14, 3:19 pm, Richard Heathfield <[e-mail].i nvalidwrote:

subramanian10.. [e-mail], 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:

On Mar 14, 3:19 pm, Richard Heathfield <[e-mail].i nvalidwrote:

>subramanian10. [e-mail], 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!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Racaille]

On Mar 15, 4:09 pm, Richard Heathfield <[e-mail].i nvalidwrote:

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

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

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!

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.