Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.wizards,comp.lang.c Subject: Re: have I found a bug in K&R? Message-ID: <9031@mimsy.UUCP> Date: Sun, 18-Oct-87 12:22:09 EDT Article-I.D.: mimsy.9031 Posted: Sun Oct 18 12:22:09 1987 Date-Received: Mon, 19-Oct-87 01:49:32 EDT References: <18668@amdcad.AMD.COM> <517@hubcap.UUCP> <321@laticorp.UUCP> <3802@elecvax.eecs.unsw.oz> Followup-To: comp.lang.c Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 39 Xref: mnetor comp.unix.wizards:4984 comp.lang.c:5005 (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