Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hadron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!rlgvax!hadron!jsdy
From: jsdy@hadron.UUCP (Joseph S. D. Yao)
Newsgroups: net.lang.c
Subject: Re: Altos C compiler funnies
Message-ID: <129@hadron.UUCP>
Date: Wed, 18-Dec-85 03:12:50 EST
Article-I.D.: hadron.129
Posted: Wed Dec 18 03:12:50 1985
Date-Received: Fri, 20-Dec-85 02:34:52 EST
References: <557@scirtp.UUCP>
Reply-To: jsdy@hadron.UUCP (Joseph S. D. Yao)
Distribution: net
Organization: Hadron, Inc., Fairfax, VA
Lines: 21

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}