Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: Use of RMS from VAX C
Message-ID: <8802210420.AA28558@ucbvax.Berkeley.EDU>
Date: 16 Feb 88 22:45:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40


	I'm trying to use the RMS services $PARSE and $SEARCH to process
	wildcard file specifications. However, the VAX C compiler (V2.3) flags
	an error "Invalid right operand of an &= operator" at this statement:

	file_fab.fab$l_nam=&file_nam;

Change the line to:

	file_fab.fab$l_nam = &file_nam;

Yes, the spaces matter!  (At one time, in the dark, distant past, the C
"assigning binary operators" were written as =+, =*, =&, and so on.  They were
changed to the modern forms - +=, *=, &= - a LONG time ago, mainly because
they can be ambiguous.  Many C compilers, VAX C included, still accept the old
forms as synonyms.  The C lexical analysis rules say that, when breaking input
into tokens, the LONGEST token starting at a given point is to be preferred,
so your input MUST be parsed as 

	file_fab.fab$l_nam =& file_nam;

which means, in modern terms,

	file_fab.fab$l_nam &= file_nam;

- not at all what you meant.  Adding the spaces forces the correct parse since
spaces cannot be embedded within tokens.

BTW, this is a rather unusual statement to get caught on.  By far the most
common "gotcha'" caused by this anachronism occurs in:

	a=-1

This does NOT assign -1 to a - it decrements a by 1!

The proposes ANSI C spec eliminates the old =op forms, so this little hook
will presumably finally fade away.  In the meantime, always surround equal
signs with spaces - it'll save you a lot of grief, and it'll make your code
a lot more readable anyway.)
							-- Jerry