braner@batcomputer.tn.cornell.edu (braner) (03/16/88)
[] The Laser C preprocessor will not take a logical OR, as in: #define AtST 1 #define MSDOS 0 ... #if (AtST || MSDOS) /* does not work! */ The solution is to write: #if (AtST | MSDOS) /* this does work */ Note that the replacement of logical OR with a bit-wise OR is safe, but one CANNOT generally replace "&&" with "&". For example: (2 && 4) == 1, but (2 & 4) == 0. I consider this a bug since in "C: A Reference Manual" by Harbison & Steele (highly recommended, look for 2nd edition!) it says explicitly that "||" is OK in the constant expression for #if. - Moshe Braner PS: Havn't received the Laser C manual yet. I sent the defective Laser C system disk I got back to Megamax, and they sent me a replacement already.
root@cca.ucsf.edu (Computer Center) (03/18/88)
In article <4057@batcomputer.tn.cornell.edu>, braner@batcomputer.tn.cornell.edu (braner) writes: > > The Laser C preprocessor will not take a logical OR, as in: > > #if (AtST || MSDOS) /* does not work! */ > > I consider this a bug since in "C: A Reference Manual" by Harbison & Steele > (highly recommended, look for 2nd edition!) it says explicitly that "||" > is OK in the constant expression for #if. > Sorry, Moshe, Harbison & Steele may be a fine book but it is not a standard document. Short of the ANSI standard getting final approval the only real C standards are K & R and the extensions in the AT&T Unix release compilers (and these certainly rank below K & R). OK, see K & R, p. 211 for the definition of `constant expressions' which are required by the preprocessor definition (p. 208). The list of allowed operators does _not_ include the logical operators && and ||. Thos Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca (The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos) OS|2 -- an Operating System for puppets. #include <disclaimer.std>
michel@megamax.UUCP (Michel Rynderman) (03/18/88)
In article 7698 Moshe Braner writes: >>The Laser C preprocessor will not take a logical OR, as in: >>#if (AtST || MSDOS) According to K & R || and && are not part of a constant expression that can be used in the preprocessor. (see page 211). Michel@megamax
braner@batcomputer.tn.cornell.edu (braner) (03/25/88)
[] Some people have alerted me to the fact that K&R do NOT include &&, ||, etc in the ops allowed in a "constant expression", so Laser C not allowing "#if (A && B)" is not a bug. I still think it is, since: 1) (A && B) is just as CONSTANT as (A & B), so it must be an oversight on the part of K&R. 2) the logical ops are explicitly included in the draft ANSI standard C. This is 1988, not 1978! Laser C supports many other things that are not in K&R (e.g., enum), so why not support this relatively trivial thing? 3) other compilers that I use allow the logical ops in #if, including UNIX compilers and Turbo C. Thus, my code is held at a low common denominator by Laser C! BTW, it is 4 weeks past the time that Megamax claimed they finally GOT the Laser C manual, and I STILL don't have it. Oh well, it's probably in the mail (3rd class)... - Moshe Braner PS Re: GNOME. I've been told that when you ftp (into tcgould.tn.cornell.edu) you are at ~ftp, so you need to "cd pub/gnome" to find GNOME. Warning: the "alt_chars" array structure in "help.c" is defect since the chars that should have the MSB set don't. If you want to compile on the ST or MS-DOS I suggest you ftp the "source.arc" file and download it first.
dmb@TIS.COM (David M. Baggett) (03/29/88)
The C compiler we are running on our Sun (which I assume is the standard BSD C compiler) has no complaint about: #define foo 1 && 0 #if 1 || 0 for(;;); #endif From what I've heard here, Laser C doesn't like || and && in constant expressions. I have to agree with Moshe Braner -- this is a bug, not a feature. Dave Baggett arpa: dmb@tis.com
jeff@polyof.UUCP (A1 jeff giordano ) (08/17/88)
Actually I wouldn't call it a bug, but more a deficience in the grammar. The following drove me nuts: for(x=-1; x<=1; x++) { ... } I wanted to loop from -1 to 1. However, the above is ambigous, it is an old style declaration. I did not find out until I tried my prog on our UNIX system. The UNIX cc gives: Warning: oldstyle declaration on line xx. Laser gives no such warning and actually takes whatever the previous value was and drecrements it by one. then does the loop. not what i thought it would do. just thought I should let someone know. Goeffrey Giordano INET: jeff@polyof.poly.edu UUCP: ...!iguana!polyof!jeff Me?!? What do I know? I'm just a brain dead poly student.
lbl@druhi.ATT.COM (Barry Locklear) (08/18/88)
In article <365@polyof.UUCP>, jeff@polyof.UUCP (A1 jeff giordano ) writes:
->
-> Actually I wouldn't call it a bug, but more a deficience in the
-> grammar. The following drove me nuts:
->
-> for(x=-1; x<=1; x++) { ... }
-> I wanted to loop from -1 to 1. However, the above is ambigous, it is an
-> old style declaration. I did not find out until I tried my prog on our
-> UNIX system. The UNIX cc gives:
-> Warning: oldstyle declaration on line xx.
->
-> Laser gives no such warning and actually takes whatever the previous
-> value was and drecrements it by one. then does the loop. not what i thought it
-> would do.
Jeff,
You probably figured this out already, but I'll send this out anyway.
Instead of using "x=-1" try "x = -1". This should parse correctly.
C originally allowed -= and =- to mean the same thing. Apparently
Laser C still let's you do this. That's why I *always* put spaces
around my operators!
Barry
rickf@iscuva.ISCS.COM (Rick Frostad) (08/19/88)
In article <365@polyof.UUCP> jeff@polyof.UUCP (A1 jeff giordano ) writes: > >Actually I wouldn't call it a bug, but more a deficience in the >grammar. The following drove me nuts: > > for(x=-1; x<=1; x++) { ... } >I wanted to loop from -1 to 1. However, the above is ambigous, it is an >old style declaration. I did not find out until I tried my prog on our >UNIX system. The UNIX cc gives: > Warning: oldstyle declaration on line xx. > >Laser gives no such warning and actually takes whatever the previous >value was and drecrements it by one. then does the loop. not what i thought it >would do. > >just thought I should let someone know. > >Goeffrey Giordano >INET: jeff@polyof.poly.edu >UUCP: ...!iguana!polyof!jeff > >Me?!? What do I know? I'm just a brain dead poly student. This illustrates both a blessing and a curse of the C language. To most C compilers the following are equivalent: x -= 1; x =- 1; Without the whitespace the compiler interpreted 'x=-1' to be the latter rather than 'x=(-1)'. Try using parens or whitespace. This also demonstates one of the possible side-effects of macros. The following illustrates the point: #define MINUS_ONE -1 x=MINUS_ONE; ...translated by the pre-processor to: x=-1; Again not what was intended. To minimize the chance of these side-effects, always use parans for signed numbers; especially when defining them in macros (#defines). #define MINUS_ONE (-1) x=MINUS_ONE; ...translated by the pre-processor to: x=(-1); In either case the use of whitespace not only eliminates the problem but also makes the code more readable... ------------------------------------------------------------------------------ iiiiii ssssscccccccc iiiiii sscccccccccccc iiiiii cccc ccccc iiiiii ss cc ccccc iiiiiis ssccccc iiiiiisss cccc iiiiiissssss cc iiiiii sss cc ccccc iiiiiis ccc ccccc iiiiiisss sssccccccccccc iiiiiissssss sssssccccccccc - Rick W. Frostad - ISC Systems Corporation - E. 22425 Appleway - Liberty Lake, WA 99019