bobd@zaphod.UUCP (Bob Dalgleish) (05/15/85)
> > Pardon my excess stupididy, but I have a question about the > ** CORRECT ** way a C-compiler (by definition) should handle the > following program. Consider main.c, below > > char *charptr; > short *shortptr; > int *intptr; > long *longptr; > main() > { > if(charptr == 32); > if(intptr == 32) ; > if(longptr== 32) ; > if(shortptr == 32 ); > } > Note that the Alcyon compiler leaves the constant alone if the > thing is a char; shifts it left one if it is an int (2 bytes), and > left two if it is a long (4 bytes). > > Bill Allen at Alcyon Corporation assures me that this is not > a bug, that constants MUST BE MULTIPLIED BY THE NUMBER OF BYTES > when doing a test with a pointer. He even swears that the regular > C compiler cc must do this. > > When you are doing a proprietary product, it is sometimes nice > to do stupid things like mixing types in an if() and having things > be handled intelligently. Of course, you can do something like: > A) The PDP-11 Unix V6 compiler did the multiply by the pointer size so that array references would be handled properly in the case of p + 32 <=> p[32] It also generated odd things in the comparisons. I remember that an (int *) function would return 0 (NULL) for one condition, a pointer to an honest-to-god int for another condition, or -1 in a third case. The -1 value got multipled by two (sizeof int) in the comparison. B) Pcc based compilers complain that you are mixing pointer and integers in an arithmetic operation. Which I think is a good thing. C) If you want to compare the pointer to the value 32 then you must (or at least should) cast the constant 32 to be of the appropriate type. If the compiler multiplies the constant by anything but one for any cast, then it is broken. -- [The opinions expressed here are only loosely based on the facts] Bob Dalgleish ...!alberta!sask!zaphod!bobd ihnp4! (My company has disclaimed any knowledge of me and whatever I might say)