XPMAINT@TAMVENUS.BITNET (Shane Davis -- CSC XPrint Programmer) (02/10/88)
Hello again...
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;
Here is the meat of the program up to this point:
#include <rms>
struct FAB file_fab;
struct NAM file_nam;
.
.
.
main()
{
.
.
.
/* (before any other initialization of RMS blocks...) */
file_fab=cc$rms_fab;
file_nam=cc$rms_nam;
.
.
.
file_fab.fab$l_nam=&file_nam;
/* (other intializations of RMS blocks) */
.
.
.
}
These declarations and initializations are done in accordance with the RMS
Manual and in this case are done exactly like the Guide to Programming in
VAX C says. I was doing it my own way without any "cc$rms_fab" business and
came up with the same error I get now when I'm doing things exactly by the book.
Please help me...if I can't get this one straightened out, I'll have to write
yet another 5-liner in MACRO to link with my C program in order to get around
yet another fluke of VAX C...
Operating system version is V4.6.
Regards,
--Shane Davis
Programming Assistant
Texas A&M Univ. Computing Svcs. Ctr. Software Systems Group
********************************************************************************
BITnet THEnet Internet
XPMAINT@TAMVENUS THOR::XPMAINT xpmaint@venus.tamu.edu
RSD1901@TAMSIGMA ZAC::RSD1901 --------
X233SD@TAMVM1 ------ x233sd@tamvm1.tamu.edu
------ CONS::RSD1901 rsd1901@cons.tamu.edu
SPAN: UTSPAN::UTADNX::(THEnet addr)
********************************************************************************m1b@rayssd.ray.com (M. Joseph Barone) (02/17/88)
In article <8802150715.AA23998@ucbvax.Berkeley.EDU> XPMAINT@TAMVENUS.BITNET (Shane Davis -- CSC XPrint Programmer) writes: > > 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; The error message is a good indication of exactly what went wrong. The old style AND bitwise operator can be represented by '=&'. Apparently, VAX C still supports this. The compiler thinks you're trying to perform an AND operation rather than store an address in a variable. To get around this problem, merely insert spaces around the '=', such as: file_fab.fab$l_nam = &file_nam; Joe Barone ---------------------------> m1b@rayssd.RAY.COM {cbosgd, gatech, ihnp4, linus, mirror, uiucdcs}!rayssd!m1b Heroes have an infinite capacity for stupidity. Thus are legends born!
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (02/17/88)
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
tim@brspyr1.BRS.Com (Tim Northrup) (02/17/88)
in article <8802150715.AA23998@ucbvax.Berkeley.EDU>, XPMAINT@TAMVENUS.BITNET (Shane Davis -- CSC XPrint Programmer) says: > > Hello again... > > 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; > > --Shane Davis Sounds like the C compiler is accepting old syntax. Try using one of the following: file_fab.fab$l_nam = &file_nam; or file_fab.fab$l_nam = (&file_nam); In older C compilers, the syntax "=+" and "+=" meant the same thing. Nowadays, the accepted standard is "+=", as in "x += 5;" to add 5 to the variable x. The same is true of the bitwise operators, that is "x &= 0x10;" was the same as "x =& 0x10;". The compiler is seeing the line you entered as using this operator, which is not what you meant. You need to force the precedence you desire using one of the lines I show above. (around here we like lots-o-whitespace, so we never run into what you did :-). Hope this helps. -- Tim -- tim@brspyr1.BRS.Com uunet!steinmetz!brspyr1!tim ============================================ Tim "The Enchanter" Northrup
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (02/17/88)
> 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; The problem is that your statement is ambiguous. It could mean either file_fab.fab$l_nam = &file_nam; or file_fab.fab$l_nam =& file_nam; which, under the original specifications for C is equivalent to file_fab.fab$l_nam &= file_nam; The VAX C compiler is apparently interpreting it as the latter. The =& is probably still accepted for compatibility reasons. The solution is to change your statement to file_fab.fab$l_nam = &file_nam;
scjones@sdrc.UUCP (Larry Jones) (02/17/88)
In article <8802150715.AA23998@ucbvax.Berkeley.EDU>, XPMAINT@TAMVENUS.BITNET (Shane Davis -- CSC XPrint Programmer) writes: > Hello again... > > 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; Easy. The compiler is misinterpreting your statement as using the old- fashioned combined assignment operator =&. Just put spaces around the = and all will be well. Just one more example of why you should *always* leave space around binary operators. -- ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
cole@sas.UUCP (Tom Cole) (02/23/88)
the question was something like "why does this burfle?" var1=&var2; isn't it true that for compatibility with old implementations of C =& and &= are the same? You could completely solve the ambiguity by using v1 = &var2; which makes = and & different tokens.
dave@wsccs.UUCP (Dave E Martin "VAX Headroom") (03/02/88)
In article <8802150715.AA23998@ucbvax.Berkeley.EDU>, XPMAINT@TAMVENUS.BITNET (Shane Davis -- CSC XPrint Programmer) writes: > 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; > > Please help me...if I can't get this one straightened out, I'll have to write > yet another 5-liner in MACRO to link with my C program in order to get around > yet another fluke of VAX C... > You have just asked the c compiler to bitwise and file_nam and file_fab.fab$l_nam. This IS DOCUMENTED in the c-compiler manual. you can fix it by separating =& with = & or =(&...). I have been using VAXC for two years EXTENSIVELY and have never had to write anything in macro to get around anything other than need of extreme speed. the =& equaling &= is left over from some earlier version of C, I'm not sure where, but this has been left in for compatibility. Also, this will occur with =* and probably any of the other "combined assignment" statements.