modifying the strings pointed to by argv

[Racaille]

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.

could you please point where those restrictions are in the standard ?
I read n869 / 5.1.2.2.1 and found nothing like that.

At the contrary, modifying *argv (for i < argc, '<' not '<=')
is explicitly allowed.

 

[Richard Heathfield]

Racaille said:

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

If you look for insults, you will find them everywhere.

Please a) be polite

I *am* being polite. You can try for impolite if you like.

b) explain

No chance. This is my last reply to you (at least for as long as I
remember). I've already stopped replying to Mr Muntyan for much the
same reason. When you guys get a clue, let me know.

 

[Yevgen Muntyan]

Racaille said:


If you look for insults, you will find them everywhere.


I *am* being polite. You can try for impolite if you like.


No chance. This is my last reply to you (at least for as long as I
remember). I've already stopped replying to Mr Muntyan for much the
same reason.

For the reason you hate anyone disagreeing with you? Or that you
hate anyone who doesn't agree that you're being kind and nice at
every moment? Man, this very thread shows how funny it is:

R: Where are no non-stupid reasons to do this.
O: Hacking to make ps display funny stuff.
R: Off-topic here, hence the above statement was
right, I was right as usual.

You love to apply "off-topic" as a last measure if you can't use
logic to shave opponent off, indeed. Your politeness is another
funny thing.

When you guys get a clue, let me know.

I did, indeed.

Yevgen

 

[CBFalconer]

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.

could you please point where those restrictions are in the standard
? I read n869 / 5.1.2.2.1 and found nothing like that.

At the contrary, modifying *argv (for i < argc, '<' not '<=')
is explicitly allowed.

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

and specifically omits any permission to modify the argv array.
The string length restrictions are just common sense.

 

[Mark McIntyre]

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

Okay, but setting aside tautological arguments, why?
--
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

 

[Richard Heathfield]

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

Okay, but setting aside tautological arguments, why?

The risk to the stability of your program is potentially high, and you
gain nothing that you can't get more safely in some other way.

 

[Francine.Neary]

The risk to the stability of your program is potentially high,

How so?

and you
gain nothing that you can't get more safely in some other way.

But, for example, small programs can sometimes be written in a very
elegant way by calling main() recursively, possibly modifying its
parameters between calls.

 

[Richard Heathfield]

(e-mail address removed) said:

How so?

If you screw up and write too much into an argv array, you're far more
likely to trash something important than if you wrote too much into
some other array. (That doesn't mean it's okay to write too much into
some other array, of course.)

But, for example, small programs can sometimes be written in a very
elegant way by calling main() recursively, possibly modifying its
parameters between calls.

<shrug> That particular game is not, in my view, worth the candle.

 

[Ben Pfaff]

But, for example, small programs can sometimes be written in a very
elegant way by calling main() recursively, possibly modifying its
parameters between calls.

I've yet to see one of these that is not better written some
other way.

 

[Francine.Neary]

I've yet to see one of these that is not better written some
other way.

How about this little factorial program? I think it's pretty cute.
E.g.
$ ./factorial 4
24


#include <stdio.h>
#include <stdlib.h>

struct s {
unsigned int f;
unsigned int n;
};

main(int argc, char **argv)
{
unsigned int i;
if(*argv) {
i=(unsigned int) atoi(argv[1]);
*argv=0;
argv[1]=malloc(sizeof(struct s));
((struct s*) argv[1])->n=i;
((struct s*) argv[1])->f=1;
}

if(((struct s*) argv[1])->n) {
((struct s*) argv[1])->f*=((struct s*) argv[1])->n--;
main(argc,argv);
return 0;
}
printf("%u\n",((struct s*) argv[1])->f);
free(argv[1]);
return 0;
}

 

[Francine.Neary]

(e-mail address removed) said:



If you screw up and write too much into an argv array, you're far more
likely to trash something important than if you wrote too much into
some other array. (That doesn't mean it's okay to write too much into
some other array, of course.)

Isn't there a school of thought that says that if you screw up it's
better to have something blow up in your face immediately, rather than
leaving a subtle, hard-to-trace bug waiting somewhere to be discovered
intermittently at some unknown future date?

 

[Mark McIntyre]

Mark McIntyre said:

The risk to the stability of your program is potentially high, and you
gain nothing that you can't get more safely in some other way.

What risk?
Sorry to go on about this, but to date I'm not aware of anyone in this
thread actually producing some evidence that this is bad. After all,
argv[n] is just another array of chars, so long as you don't walk off
the end of it, there's no more risk than with any other array of
chars.
--
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

 

[Mark McIntyre]

(e-mail address removed) said:


If you screw up and write too much into an argv array, you're far more
likely to trash something important than if you wrote too much into
some other array.

C&V please.
--
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

 

[Ben Pfaff]

How about this little factorial program? I think it's pretty cute.

It's a 28-line program (including blank lines and #includes) that
uses 7 casts. Not my idea of "cute".

 

[CBFalconer]

C&V please.

No such, just common sense. Those variables are setup before
entering main, so they are likely to be surrounded by sensitive
system data, which you can mung.

 

[Richard Heathfield]

(e-mail address removed) said:

Isn't there a school of thought that says that if you screw up it's
better to have something blow up in your face immediately, rather than
leaving a subtle, hard-to-trace bug waiting somewhere to be discovered
intermittently at some unknown future date?

Yes, absolutely, but C doesn't offer any guarantee that trashing
something important will get you an immediate blow-up at a time
convenient to you.

 

[Richard Heathfield]

Mark McIntyre said:

Mark McIntyre said:

The risk to the stability of your program is potentially high, and you
gain nothing that you can't get more safely in some other way.

What risk?
Sorry to go on about this, but to date I'm not aware of anyone in this
thread actually producing some evidence that this is bad. After all,
argv[n] is just another array of chars, so long as you don't walk off
the end of it, there's no more risk than with any other array of
chars.

You're right. As long as your code is perfect, nothing bad can happen.

Gosh.

 

[Richard Heathfield]

(e-mail address removed) said:

How about this little factorial program? I think it's pretty cute.

<snip>

Here are some results from that program:

../foo
Segmentation fault (core dumped)
../foo -h
1
../foo 0 /* it actually gets this right, which was a mild surprise */
1

Every non-negative integer argument up to and including 12 works fine,
but observe what happens when we exceed 12:

../foo 13
1932053504

(the correct value is of course 6227020800).

So you have a seriously convoluted program which only works for a
vanishingly small percentage (less than 0.2%) of possible valid inputs.
My own factorial program is, alas, twice as long as yours (58 lines),
not including library code of course - but it continues to get the
answers right long past 13, despite not taking advantage of ISO's
licence to write into argv. For example, compare this:

../foo 52
0

with this:

~/path/to/rjhfactorial 52
80658175170943878571660636856403766975289505440883277824000000000000

 

[CBFalconer]

(e-mail address removed) said:

<snip>

Here are some results from that program:

./foo
Segmentation fault (core dumped)
./foo -h
1
./foo 0 /* it actually gets this right, which was a mild surprise */
1

Every non-negative integer argument up to and including 12 works
fine, but observe what happens when we exceed 12:

./foo 13
1932053504

(the correct value is of course 6227020800).

So you have a seriously convoluted program which only works for a
vanishingly small percentage (less than 0.2%) of possible valid inputs.
My own factorial program is, alas, twice as long as yours (58 lines),
not including library code of course - but it continues to get the
answers right long past 13, despite not taking advantage of ISO's
licence to write into argv. For example, compare this:

./foo 52
0

with this:

~/path/to/rjhfactorial 52
80658175170943878571660636856403766975289505440883277824000000000000

Mine produces <grin> :

[1] c:\c\junk>fact 52
Factorial(52) == 2147483648e12 * pow(3,23) * pow(7,8) * pow(11,4) *
pow(13,4) *
pow(17,3) * pow(19,2) * pow(23,2) * pow(29,1) * pow(31,1) *
pow(37,1) * pow(41,1
) * pow(43,1) * pow(47,1) * pow(2,6)
or approximately
806581751709438768400000000000000000000000000000000000000000000
00000.

without any fancy bignum arithmetic packages.

 

[Francine.Neary]

It's a 28-line program (including blank lines and #includes) that
uses 7 casts. Not my idea of "cute".

I suppose one could #define CAST (struct s*) to make the code look
prettier.