Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rit!ultb!jed4885
From: jed4885@ultb.UUCP (J.E. Dyer)
Newsgroups: comp.arch
Subject: Re: looking for >32-bit address space [and how will C handle it]
Summary: this should probably be in some other news group, press n if
	 you're not interested in C.
Message-ID: <684@ultb.UUCP>
Date: 14 Apr 89 19:37:17 GMT
References: <1032@myrias.UUCP> <12289@reed.UUCP> <16568@winchester.mips.COM> <1326@softway.oz>
Reply-To: jed4885@ultb.UUCP (J.E. Dyer (713ICS))
Organization: Rochester Institute of Technology, Information Systems
Lines: 26

In article <1326@softway.oz> chris@softway.oz (Chris Maltby) writes:
>In article <16568@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
> [Stuff about C data types, and why it's a bad idea to make long ints]
> [64 bits deleted to save bandwidth.]

	I was thinking about this today, and wondered why not change C
	slightly so that the size of an enumerated object (ints, chars,
	longs, etc) was explicitly defined.  Perhaps int1, int2, int4,
	int8 etc would be a good way of doing it (i.e. the number of
	bytes would be explicityly stated in the definition).  I think
	this would help make C more portable, as I've seen perfectly
	good (well not perfect...) C code break on various machines
	because ints were 16 bits on one machine and 32 on another.
	Of course you could do this with #define statements, but it
	shouldn't be too hard to write a compiler that deals with
	arbitrary sized ints (i.e. things like int16 etc.) in a fairly
	optimal way (are there any machines out there that won't let you
	do multi word arithmetic?  I know the 680x0 series has an X bit
	or some such that makes this possible...).

							-Jason

-sig-of-the-day-
Disclaimer: "I'm just an undergrad."
Bitnet: JED4885@RITVAX		UUCP: Your guess is as good as mine.
"I'm anti-war, but not necessarily anti-violence, ya know?" -John