MCDONALD@UMKCVAX1.BITNET (10/29/86)
The following program WON'T compile as is:
==================
/* from page 1-20 PROGRAMMING IN VAX C */
#include stdio
int *pointer;
int x=10, y=0;
main()
{
pointer=&x;
y=*pointer;
printf("values are %d %d %d\n",pointer,x,y);
}
===================
but will with these changes:
===================
pointer= &x;
y= *pointer;
===================
Is this a *known* bug??
GaryM. BITNET contact UMKCVAXn (n=1,3)
Univ. of Mo. at K.C.
MCDONALD @ UMKCVAX1 . BITNETgwalker@SPCA.BBN.COM (Gail Rubin Walker) (10/30/86)
As I understand it, in earlier days of C, the constructs += -= *= etc were coded in the reverse form: =+ =- =* and C compilers still seem to be on the lookout for the latter form to warn you to change your program. Given that '=*', for example, is one of those, a line like x=*pointer; is ambiguous. It could mean either x =* pointer; /* old style of *= OR */ x = *pointer; /* what you intended */ You don't mention what the error was that you got from compilation but I suspect it was related to this. Solution - put more spaces in your code. (My personal opinion is that its more readable with more spaces anyway.) -- Gail Walker
campbell@maynard.UUCP (10/31/86)
In article <8610301127.AA01047@ucbvax.berkeley.edu> MCDONALD@UMKCVAX1.BITNET writes: >The following program WON'T compile as is: ... > pointer=&x; > y=*pointer; ... >but will with these changes: ... > pointer= &x; > y= *pointer; ... >Is this a *known* bug?? This isn't a bug, it's a feature. pointer =& x; means pointer = pointer & x; y =* pointer; means y = y * pointer; Check your K&R. This syntax is considered obsolete, (the current syntax is "pointer &= x", not "pointer =& x"), but many compilers either support the old syntax or recognize it and complain about it. -- Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc. UUCP: {alliant,wjh12}!maynard!campbell 120 Fulton Street, Boston MA 02109 ARPA: campbell%maynard.uucp@harvisr.harvard.edu (617) 367-6846
S170MIKO@HTIKHT5.BITNET (10/31/86)
Gary McDonald writes: > The following program WON'T compile as is: > > ================== > /* from page 1-20 PROGRAMMING IN VAX C */ > #include stdio > int *pointer; > int x=10, y=0; > main() > { > pointer=&x; > y=*pointer; > printf("values are %d %d %d\n",pointer,x,y); > } > =================== > but will with these changes: > =================== > pointer= &x; > y= *pointer; > =================== > > Is this a *known* bug?? Well, you're wrong both ways: this is *not exactly* the way the example in the manual is written, and it is not a bug but a *feature*. The problem is that this is one of the few cases where spacing is significant, and it is meant to be. This is because =& and =* are actually alternative ways to write the operators &= and *= , and with a space in between they mean just what you think they mean. This is mentioned (briefly) in the manual on pages 4-19 & 4-20. The examples in the manual always include lots of (insignificant) spaces just to improve readability, so it's not obvious that these two spaces immediately after = are really necessary to avoid ambiguity, but they are there in the example. By the way, if you're working through the examples in chapter 1 you'll probably have found the *real* error in example 1-6: the statement _tolower(ch) should of course be ch = _tolower(ch). Michiel -- Michiel Koren EARN/Bitnet: s170miko@htikht5.BITNET Tilburg University SURFnet: kubvx1::s170miko Netherlands
LEICHTER-JERRY@YALE.ARPA (11/01/86)
The following program WON'T compile as is:
==================
/* from page 1-20 PROGRAMMING IN VAX C */
#include stdio
int *pointer;
int x=10, y=0;
main()
{
pointer=&x;
y=*pointer;
printf("values are %d %d %d\n",pointer,x,y);
}
===================
but will with these changes:
===================
pointer= &x;
y= *pointer;
===================
Is this a *known* bug??
This is not a bug; it's a vestige of the past history of C. Originally, C
placed the binary operator AFTER the "=" in assigning operators; what is
today written as:
a += 3;
was once written as:
a =+ 3;
The ordering was changed - a LONG time ago - because it lead to a variety of
situations that, while not technically ambiguous - for a reason I'll explain
below - were confusing. For example, you'd probably expect:
a=-3;
to assign -3 to a, but in fact it is parsed as:
a =- 3;
and subtracts 3 from a. Or consider the classic, if unlikely:
a=/*x ... are we in a comment here?
While the old-style assigning operators are obsolescent, most current C
compilers - VAX C included - continue to support them to avoid breaking old
code (of which there is probably very little, if any, left). The draft ANSI
standard for C finally declares the old format dead - along with old-style
initializers, which look like current initializers without the "=". However,
the standard is still a draft.
There is one additional factor in the equation: a=-3 has SOME interpretation,
even if a compiler-dependent one. In fact, K&R specify the interpretation by
requiring that C tokens be "as long as possible"; that is, a K&R-compliant C
compiler MUST parse the "=-" as a single token, not as the two successive
tokens "=" and "-". Without this kind of a rule, there are other ambiguities
in C; for example, is
a+++b
to be parsed as:
a++ + b
or as
a + ++b
With the "longest possible token" rule, we see that the first of these is
"correct". BTW, consider:
--b;
Without the "longest possible token" rule, this COULD be parsed as if it were:
-(-b);
which would probably make you pretty unhappy!
Anyway, since a token cannot contain an imbedded space, writing
y= *pointer;
forces the interpretation you had in mind - though personally I would never
write such a monstrocity - put spaces around your equal signs and make your
code SO much more readable:
y = *pointer;
This, BTW, is what the example on page 1-20 REALLY says - you've typed it in
without all the spaces. Put the spaces back and it'll work fine.
You may object that whitespace "is not significant in C". Sorry, that's
just not true, as the examples show. Never has been; is not in the draft ANSI
C spec. What IS true is that a single whitespace character is equivalent to
any (non-zero!) number of them.
All of this is discussed, by the way, in section 4.7 of PROGRAMMING IN VAX C.
-- Jerry
-------Leisner.Henr@XEROX.COM (marty) (11/02/86)
Gary, I don't use the VAX C compiler, but this seems reasonable, knowing about early implementations of C allowed =<operator> instead of <operator>=. Also it is better style to seperate variables off operators by a space. If you want, I could try the sample you sent on a variety of C compilers I use. marty