char **argv vs. char* argv[]

[Bret]

I'm curious why char** argv is acceptable in the main() declaration.

In the comp.lang.c FAQ (question 6.18) it says that pointers to
pointers and pointers to an array are not interchangable. However the
declaration:

int main(int argc, char** argv)

is common.

How does that work out? Shouldn't the compiler complain if you're not
doing:

int main(int argc, char* argv[])

Thanks,
Bret

[Joona I Palaste]

Bret <bl***@yahoo.co m> scribbled the following:

I'm curious why char** argv is acceptable in the main() declaration. In the comp.lang.c FAQ (question 6.18) it says that pointers to
pointers and pointers to an array are not interchangable. However the
declaration: int main(int argc, char** argv) is common. How does that work out? Shouldn't the compiler complain if you're not
doing: int main(int argc, char* argv[])

This is because in function parameter declarations, char **foo and
char *foo[] are the same thing. Not just in main(), but in every other
function too. What's more, int **foo and int *foo[] are also the same.
So are int ***foo and int **foo[].
In fact, in general, if T is a type, then T *foo and T foo[] are the
same thing in function parameter declarations. (This goes ONLY one
level deep - T **foo and T foo[][] are a different matter entirely!)
This is all explained by Chris Torek's THE RULE. If used as a value,
or as a function parameter, an array decays into a pointer into its
first element. Therefore you can't really pass arrays into functions
at all. You can pass pointers to arrays, or structures containing
arrays, but not arrays themselves.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley

[Brett Frankenberger]

In article <a1************ **************@ posting.google. com>,
Bret <bl***@yahoo.co m> wrote:

I'm curious why char** argv is acceptable in the main() declaration.

In the comp.lang.c FAQ (question 6.18) it says that pointers to
pointers and pointers to an array are not interchangable. However the
declaration:

int main(int argc, char** argv)

is common.

char **argv declares argv as a pointer to a pointer to a character
char *argv[] declares argv as am array of pointers to a character

There are no pointers to arrays in either case. So whether or not
pointers to arrays are interchangable with pointers to pointers is
irrelevant to whether "char **argv" and "char *argv[]" are both
allowable as the second parameter to main().

The relevant question you would want to ask is whether arrays and
pointers are interchangable. They aren't in the general case, in the
formal parameter list of a function, they more-or-less are with respect
to the outer-most nesting layer.

-- Brett

[E. Robert Tisdale]

Bret wrote:

I'm curious why char** argv is acceptable in the main() declaration.

In the comp.lang.c FAQ (question 6.18) it says that
pointers to pointers and pointers to an array are not interchangeable .
However the declaration:

int main(int argc, char** argv)

is common.

How does that work out?
Shouldn't the compiler complain if you're not doing:

int main(int argc, char* argv[])
It probably should complain.
cat f.c int f(char* s[]) {
char** p = s;
}
gcc -Wall -std=c99 -pedantic -c f.c f.c: In function `f':
f.c:2: warning: unused variable `p'
f.c:3: warning: control reaches end of non-void function

C performs an "implicit conversion"
from an array to a pointer to its first element
and from a pointer to an array.

I can write
cat f.c int f(char* s[]) {
char** p = s;
return f(p);
}
gcc -Wall -std=c99 -pedantic -c f.c

and my compiler will not complain.

[Irrwahn Grausewitz]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in
<3F**********@j pl.nasa.gov>:

Shouldn't the compiler complain if you're not doing:

int main(int argc, char* argv[])
It probably should complain.

Why?

> cat f.c

int f(char* s[]) {
char** p = s;
}

> gcc -Wall -std=c99 -pedantic -c f.c

f.c: In function `f':
f.c:2: warning: unused variable `p'
f.c:3: warning: control reaches end of non-void function

Your compiler complains about you having declared an automatic variable
without using it and to not return a value from a function that is
declared as returning int. This has no relation to the given problem.
C performs an "implicit conversion"
from an array to a pointer to its first element
Right, when used as a value or formal parameter.
and from a pointer to an array.
Huh?
ITYM one can apply the '[]' operator to a pointer like
one would do with an array, so that:

int i = 21;
int a[42];
int *p = a;

leads to:

p[i] == a[i];

I can write

> cat f.c

int f(char* s[]) {
char** p = s;
return f(p);
}

> gcc -Wall -std=c99 -pedantic -c f.c

and my compiler will not complain.

Yes, because this time you use p *and* you (formally) return a
value while in fact f() won't return anything at all as it will
crash your program when called because of infinite recursion.

Irrwahn

--
If it's not on fire, it's a software problem.

[E. Robert Tisdale]

Irrwahn Grausewitz wrote:

E. Robert Tisdale wrote:

Shouldn't the compiler complain if you're not doing:

int main(int argc, char* argv[])
It probably should complain.

Why?

> cat f.c

int f(char* s[]) {
char** p = s;
}

> gcc -Wall -std=c99 -pedantic -c f.c

f.c: In function `f':
f.c:2: warning: unused variable `p'
f.c:3: warning: control reaches end of non-void function

Your compiler complains about you having declared an automatic variable
without using it and to not return a value from a function that is
declared as returning int. This has no relation to the given problem.

C performs an "implicit conversion"

from an array to a pointer to its first element

Right, when used as a value or formal parameter.

and from a pointer to an array.

Huh?
ITYM one can apply the '[]' operator to a pointer like
one would do with an array, so that:

int i = 21;
int a[42];
int *p = a;

leads to:

p[i] == a[i];

I can write

> cat f.c

int f(char* s[]) {
char** p = s;
return f(p);
}

> gcc -Wall -std=c99 -pedantic -c f.c

and my compiler will not complain.

Yes, because this time you use p *and* you (formally) return a
value while in fact f() won't return anything at all as it will
crash your program when called because of infinite recursion.

Now that you've caught up with everyone else, please explain
expand f.c #include <stdio.h>

int f(char* s[10]) {
char** p = s;
fprintf(stdout, "%d = sizeof(s)\n", sizeof(s));
fprintf(stdout, "%d = sizeof(p)\n", sizeof(p));
return 0;
}

int main(int argc, char* argv[]) {
char * s[10];
fprintf(stdout, "%d = sizeof(s)\n", sizeof(s));
return f(s);
}
gcc -Wall -std=c99 -pedantic -o main f.c
./main

40 = sizeof(s)
4 = sizeof(s)
4 = sizeof(p)

[Arthur J. O'Dwyer]

On Mon, 1 Sep 2003, Irrwahn Grausewitz wrote:

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in
<3F************ **@jpl.nasa.gov >:

Now that you've caught up with everyone else, please explain

> gcc -Wall -std=c99 -pedantic -o main f.c
> ./main

40 = sizeof(s)
4 = sizeof(s)
4 = sizeof(p)

All I can see is that on your system
10*sizeof(char* ) == 40 and sizeof(char**) == 4.
Not very surprisingly, I have to add.

Where's the joke?

Tisdale is a troll. Please just correct his posts quietly and
move away; or just ignore them, as I've learned to do. (And
yes, the "is he really at NASA?" question has been beaten to
death several times already. Check Google Groups.)

-Arthur

[Richard Heathfield]

E. Robert Tisdale wrote:

Now that you've caught up with everyone else,
Don't be unpleasant, especially when you're wrong.
please explain
Delighted.

> expand f.c

Syntax error.
#include <stdio.h>

int f(char* s[10]) {
char** p = s;
fprintf(stdout, "%d = sizeof(s)\n", sizeof(s));
fprintf(stdout, "%d = sizeof(p)\n", sizeof(p));

At the very least, on systems where a size_t is larger than an int the
behaviour is undefined.

Note that your demo program doesn't meet the requirements of the question,
which nowhere mentions char *s[10]. Still, never mind that. Observe:

rjh@tux:~/scratch> cat foo.c
#include <stdio.h>

void foo(char **r, char *s[], char *t[10])
{
printf("sizeof r = %lu\n", (unsigned long)sizeof r);
printf("sizeof s = %lu\n", (unsigned long)sizeof s);
printf("sizeof t = %lu\n", (unsigned long)sizeof t);
}

int main(int argc, char **argv)
{
if(argc >= 10)
{
foo(argv, argv, argv);
}
else
{
char *tmp[10];
foo(argv, argv, tmp);
}
return 0;
}

rjh@tux:~/scratch> ./foo 1 2 3 4 5 6 7 8 9 10
sizeof r = 4
sizeof s = 4
sizeof t = 4
Now for some history. Here are the first few lines of the source code from a
***very*** early C compiler. Regular readers will note the irony of my
quoting from it:

/* C compiler

Copyright 1972 Bell Telephone Laboratories, Inc.

*/

ossiz 250;
ospace() {} /* fake */

init(s, t)
char s[]; {
extern lookup, symbuf, namsiz;
char symbuf[], sp[];
int np[], i;

i = namsiz;
sp = symbuf;
while(i--)
if ((*sp++ = *s++)=='\0') --s;
np = lookup();
*np++ = 1;
*np = t;
}

Note the usage of np, which is defined as int np[], and used like this:
*np++ = 1;

Clearly, this is pointer syntax. [] was, in fact, used for pointer notation
early in C's development. Eventually, it was changed, but the usage of []
in function parameter lists lives on. It /still/ means pointer, in that
context.

Brian W Kernighan writes, in K&R2 starting at the foot of p99, "As formal
parameters in a function definition, char s[]; and char *s; are equivalent;
we prefer the latter because it says more explicitly that the parameter is
a pointer."

I don't expect Mr Tisdale to understand this, of course, but some other
people might find it interesting.

--
Richard Heathfield : bi****@eton.pow ernet.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

[E. Robert Tisdale]

Richard Heathfield wrote:

Note that your demo program doesn't meet the requirements of the question,
which nowhere mentions char *s[10]. Still, never mind that. Observe:

> cat foo.c
#include <stdio.h>

void foo(char **r, char *s[], char *t[10]) {
printf("sizeof r = %lu\n", (unsigned long)sizeof r);
printf("sizeof s = %lu\n", (unsigned long)sizeof s);
printf("sizeof t = %lu\n", (unsigned long)sizeof t);
}

int main(int argc, char* argv[]) {
if(argc >= 10) {
foo(argv, argv, argv);
}
else {
char *tmp[10];
foo(argv, argv, tmp);
}
return 0;
}

> ./foo 1 2 3 4 5 6 7 8 9 10
sizeof r = 4
sizeof s = 4
sizeof t = 4

Now for some history.
Here are the first few lines of the source code
from a ***very*** early C compiler.
Regular readers will note the irony of my quoting from it:

/* C compiler

Copyright 1972 Bell Telephone Laboratories, Inc.

*/

ossiz 250;
ospace() {} /* fake */

init(s, t)
char s[]; {
extern lookup, symbuf, namsiz;
char symbuf[], sp[];
int np[], i;

i = namsiz;
sp = symbuf;
while(i--)
if ((*sp++ = *s++)=='\0') --s;
np = lookup();
*np++ = 1;
*np = t;
}

Note the usage of np, which is defined as int np[], and used like this:
*np++ = 1;

Clearly, this is pointer syntax. [] was, in fact, used for pointer notation
early in C's development. Eventually, it was changed
but the usage of [] in function parameter lists lives on.
It /still/ means pointer, in that context.

Brian W Kernighan writes, in K&R2 starting at the foot of p99,
"As formal parameters in a function definition,
char s[]; and char *s; are equivalent; we prefer the latter
because it says more explicitly that the parameter is a pointer."
That's pretty good.
Now, perhaps you are ready to answer Bret's question,
"Shouldn't the compiler complain if you're not doing:

int main(int argc, char* argv[])?"

The answer is that it should. I don't know why it doesn't.
It appears that you believe that
the reason has something to do with legacy code
which treats T t[] as pointer syntax like T t*
*in a function argument list*.
Please cite and quote the relevant *rational*
from the ANSI/ISO C standard if you can.

I don't expect Mr Tisdale to understand this, of course,
but some other people might find it interesting.

Don't be unpleasant, especially when you're wrong.

[Irrwahn Grausewitz]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote:

Please cite and quote the relevant *rational*
from the ANSI/ISO C standard if you can.

Read JTC1/SC22/WG14 N843 6.7.5.3#6 if you can,
then rip out the page, eat it & choke.

--
Yah, I know, I should not feed the trolls.