Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!nike!ucbcad!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: VAX C bug
Message-ID: <8611011407.AA23138@ucbvax.berkeley.edu>
Date: Sat, 1-Nov-86 09:07:22 EST
Article-I.D.: ucbvax.8611011407.AA23138
Posted: Sat Nov  1 09:07:22 1986
Date-Received: Mon, 3-Nov-86 21:35:14 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 103
Approved: info-vax@sri-kl.arpa


    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
-------