Other 'significant' blanks

[Morris Keesan]

--------------------------------
> From: kpmartin at watmath.UUCP (Kevin Martin)
> Subject: Other 'significant' blanks
> Should a compiler allow blanks between the 'op' and the '=' in an
> 'op=' operation? e.g. should
>    a | = 4;
> be legal?
> What about other multi-character operators (like ++)?
> .
> .
> .
> There seems to be no good reason to allow such a blank, and for certain
> operators (such as --) allowing a blank would create (more) ambiguity.
> Perhaps the compiler which allows such blanks should just be called buggy.
>                       Kevin Martin, UofW Software Development Group

>From the C Reference Manual:

------
    2. Lexical conventions
	There are six classes of tokens: identifiers, keywords, constants,
    strings, operators, and other separators. . . . [White space is] ignored
    except as [it] serves to separate tokens.

    7.2 Unary operators
	[ ++ and -- are referred to as "operators"]

    7.14 Assignment operators
	. . . The two parts of a compound assignment operator are separate
    tokens.
------

    From this I read that tokens may not have spaces in them, operators are
tokens, ++ and -- are operators, and therefore ++ and -- may not have spaces
in them.  The same reasoning would apply to compound assignment operators
(e.g. +=), except for the explicit (and somewhat mystifying) exception in
7.14.  Several months ago I noticed that our C compiler allowed blanks in the
compound assignment operators, and I was about to fix this when I came across
the exception.  I see no reason why the exception should be there, and if I
were specifying the language from scratch, I wouldn't put in the exception,
but any compiler which claims to compile K&R C is buggy if it doesn't accept
white space in compound assignment operators.


-- 
			    Morris M. Keesan
			    {decvax,linus,ihnp4,wivax,wjh12,ima}!bbncca!keesan
			    keesan @ BBN-UNIX.ARPA