Why can't we declare an argv variable?

[CJ]

Functions can accept "argv like" variable definitions, i.e. foo(int
argc, char *argv[]), which was defined/initialized in the C start up
stubs, but we can't declare one for our own use.

Example:

foo(char *args[]) { /* implementation excluded }; // ok

int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error;

foo(myarr);
}

This once was allowed, but removed and I don't understand why? If a
function receiving an argv-like pointer is not problematic, why
declaration of these a problem?

cj

[Ian Malone]

CJ wrote:

Functions can accept "argv like" variable definitions, i.e. foo(int
argc, char *argv[]), which was defined/initialized in the C start up
stubs, but we can't declare one for our own use.

Example:

foo(char *args[]) { /* implementation excluded }; // ok Equivalent to foo(char **args);
(Function should have a type though,
void foo (char **args);)
Since the array decomposes to a pointer on calling the function.
Fine.


int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error; Declaring an array of automatic length, with an initialiser which the
compiler can't determine the length from.
char **mayarr = calloc(10,sizeo f(char *));

or

char **myarr = calloc(10,sizeo f(*myarr));
Doing calloc on a pointer is a bad idea though.

foo(myarr);
}

This once was allowed, but removed and I don't understand why? If a
function receiving an argv-like pointer is not problematic, why
declaration of these a problem?

--
imalone

[Chris Dollin]

CJ wrote:

Functions can accept "argv like" variable definitions, i.e. foo(int
argc, char *argv[]), which was defined/initialized in the C start up
stubs, but we can't declare one for our own use.
I'm afraid you're wrong.
Example:

foo(char *args[]) { /* implementation excluded }; // ok
`args` is declared as `char *[]`, and rewritten (because it's an array
argument to a function) as `char **`.
int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error;
Yes, because `myarr` is an array (not a pointer) and you can't
assign to arrays in C.

Declare `myarr` as `char **` and you'll be fine. Urm, better make sure
you `#include <stdlib.h>`. Also better would be

char **myarr = calloc( 10, sizeof (*myarr) );

as part of the general mallocating idiom. And, since calloc fills the
/bytes/ with 0s, but this isn't specified or guaranteed to make the
/char */ values null, use:

malloc( 10 * sizeof (*myarr) );

and initialise the store explicitly.

Then:
foo(myarr);
`foo` has no way to tell how big `myarr` is; better make sure to fix that.
}

This once was allowed,
Was it?
but removed and I don't understand why? If a
function receiving an argv-like pointer is not problematic, why
declaration of these a problem?

It isn't. You just have to remember that parameters that look like
they have type Spoo[] are rewritten to be type Spoo*. This is not news.

--
Chris "seeker" Dollin
"Who do you serve, and who do you trust?" /Crusade/

[Vladimir Oka]

CJ wrote:

Functions can accept "argv like" variable definitions, i.e. foo(int
argc, char *argv[]), which was defined/initialized in the C start up
stubs, but we can't declare one for our own use.

Example:
You'll need:

#include <stdlib.h>

here, for `calloc()`.
foo(char *args[]) { /* implementation excluded }; // ok
Don't use C++ style comments, at least not on Usenet.
You're missing a `return` here, and don't rely on implicit `int`.
int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error;
What were you trying to achieve here? Did you mean:

char **myarr = calloc(10,sizeo f(char *));
foo(myarr);
}

This once was allowed, but removed and I don't understand why? If a
function receiving an argv-like pointer is not problematic, why
declaration of these a problem?

I don't undestand your problem.
With fixes as above, it's OK (in C99, at least).

[Chris Dollin]

Chris Dollin wrote:

int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error;

Yes, because `myarr` is an array (not a pointer) and you can't
assign to arrays in C.

Grr. You can't /assign/ to them, but you can /initialise/ them. The
initialiser has to be a bunch of values inside {}, which that call
isn't.

--
Chris "brain? what brain?" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

[CJ]

Chris Dollin wrote:

Chris Dollin wrote:

int main(int argc,char *argv[])
{
char *myarr[] = calloc(10,sizeo f(char *)); // compiler error;

Yes, because `myarr` is an array (not a pointer) and you can't
assign to arrays in C.

Grr. You can't /assign/ to them, but you can /initialise/ them. The
initialiser has to be a bunch of values inside {}, which that call
isn't.

--
Chris "brain? what brain?" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

Thanks to all, but I was not seeking help on writting code and/or info
on STDC headers.

The compiler does not complain when "*arr[]" is part of a function
declaration/definition, however it prevents declaration and creation of
the "variable" array (since C99?). I am curious as to why this syntax
was removed, that all.

It seems to me "char *arr[]" is more descriptive to a follow on
programmer thqt arr is an array of char pointers, and "char **arr" is a
pointer to a char pointer. Both provide the compiler all it needs to
increment/decrement the pointer, with the only "missing" information,
the dimension, prevents a compiler from doing a bounds check.

Do any C99 compilers do bounds checks? For example;

char *arr[10];

arr[10] = "my string";

Will assigning my string to an out of bounds dimension generate a
compiler warning/error? GCC 4.0.2 does not seem to mind the
programming bug.

cj

[CJ]

CJ wrote:

Chris Dollin wrote:

Chris Dollin wrote:

Grr. You can't /assign/ to them, but you can /initialise/ them. The
initialiser has to be a bunch of values inside {}, which that call
isn't.

Never mind, Mr Dollin answered my question, arr is NOT treated as a
pointer and thus cannot be incremented or decremented.

cj