black@ee.UCLA.EDU (02/18/87)
> ) sherm@elxsi.UUCP (Michael Sherman) writes > ) [ ... ] Moral arguments aside, we're stuck with int==long. > > This silly assumption is what makes it so hard to port code written > on a vax or 68K to a 16-bit machine. In Algol 68 there is a provision for infinite precision arithmetic (theoretically anyway--I don't know if anyone ever implemented such a compiler). Each time one prepends the word "long" to a variable declaration, the compiler doubles the number of bits reserved. (Or perhaps adds a constant factor--I forget.) This would be a real nice feature for C. Of course, by use of some tricky (machine-dependent) bit-fiddling, one can implement 64 bit long ints with two longs, but that flies in the face of the whole Unix/C philosophy. Remember this next time Santa asks what you want for Christmas! Rex Black black@ee.ucla.edu ARPA ...!{ihnp4,ucbvax,sdcrdcf,trwspp}!ucla-cs!uclaee!black UUCP No age of reason Is landing upon us-- This is the age Of video violence. -- Lou Reed
snoopy@doghouse.UUCP (02/26/87)
In article <4515@brl-adm.ARPA> black@ee.UCLA.EDU (Rex Black) writes: > [...] by use of >some tricky (machine-dependent) bit-fiddling, one can implement >64 bit long ints with two longs, but that flies in the face of >the whole Unix/C philosophy. Didn't v6 use a struct of two ints to get 32 bits for time_t? (Before C had 'long') Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com