guy%gorodish@Sun.COM (Guy Harris) (09/30/87)
(This is a C question, not a UNIX question.) > on page 110 of K&R it says: > > "...(argv) is a pointer to an array of character strings..." > > but since the primary-expression operator [] has higher priority than > the unary operator *, then isn't it more correct to say that argv > (which is defined as char *argv[]) is an array of pointers to character > strings? No, it is more correct to say that "argv" is a pointer to the first element of an array of pointers to "char", which can be read as "'argv' is a pointer to the first element of an array of pointers to character strings". "argv" is *properly* declared as "char **argv"; however, if you declare an array of type X as an argument to a function, the compiler interprets that as a declaration of a pointer to type X instead. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
chris@mimsy.UUCP (Chris Torek) (10/18/87)
(This discussion should have been in comp.lang.c; followups have been directed there.) In article <3802@elecvax.eecs.unsw.oz> cameron@elecvax.eecs.unsw.oz (Cameron Simpson) writes: >... An lvalue is something which may occur on the left-hand side of an >assignment statement. If I say > char s[]; /* a character array of unspecified size */ > char *t; /* a pointer to a character */ >then I may say `t++;' or `t = s;' or `t = &s[2];' and so on. >I may not say `s++;' or `s = t;'. True enough, except . . . . >This applies whether they are declared as formal parameters or as >external array declarations. I often declare functions like > fn(a,b) > char *a; > char b[]; >in order to *prevent* myself from changing b during the function. . . . this does not work in (some? many? most? all?) compilers. PCC is perfectly happy with `b = a' inside the code for `fn'. I am not sure whether the draft has anything to say on the subject. Incidentally, with the addition of `const', ANSI now has the concept of `modifiable lvalues', so that in const int n = 4; `n' is an lvalue, but not a modifiable lvalue. (At least, I think this is how it works---there are odd possibilities like const volatile int *clockaddr = (int *)CLOCK_ADDRESS; that I am still not sure about.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris