[net.lang.c] Altos C compiler funnies

dfh@scirtp.UUCP (David F. Hinnant) (12/10/85)

We have an Altos 586 running Xenix 3.0.  To us, the C compiler has some
rather unusual restrictions.  Specificly, the following declarations are
NOT allowed:
	
	long i; 		MUST be declared as "long int"
	short int i;		MUST be declared as "short"
	unsigned long i;	doesn't work at all
	unsigned long int i;	ditto


However both "unsigned i;" and "unsigned int i;" work OK.  The compiler
error message from "short i;" is "Type clash" while the error message from
"long i;", "unsigned long i", etc. is "misplaced long".

Is this normal for Xenix C compilers, or is just the Altos funny?


-- 
				David Hinnant
				SCI Systems, Inc.
				...{decvax, akgua}!mcnc!rti-sel!scirtp!dfh

jsdy@hadron.UUCP (Joseph S. D. Yao) (12/18/85)

In article <557@scirtp.UUCP> dfh@scirtp.UUCP (David F. Hinnant) writes:
>We have an Altos 586 running Xenix 3.0.  ...
>	long i; 		MUST be declared as "long int"
>	short int i;		MUST be declared as "short"
>	unsigned long i;	doesn't work at all
>	unsigned long int i;	ditto
>However both "unsigned i;" and "unsigned int i;" work OK.  The compiler
>error message from "short i;" is "Type clash" while the error message from
>"long i;", "unsigned long i", etc. is "misplaced long".

Several early C compilers didn't allow unsigned longs, because it
wasn't easy on their architectures.  I auppose that's what's going
on there.  On the Altos 586 running Xenix 2.[35][abc] we had no
problem with {long|short} [int] i; although since (again) early
compilers treated long and short as qualifiers to the "real" data
type I keep using "long int" and "short int".  The fact that they
seem to be treated opposite in your compiler must be a bug.  Have
you tried these all isolated, and with different variable names?
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}