Not: Question of Ignorance

[Bob Dalgleish]

> 
>     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)