Date: Sun, 26 Nov 1995 12:22:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: grog@lemis.de Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: How long is long? Message-ID: <199511261922.MAA15217@phaeton.artisoft.com> In-Reply-To: <199511261252.NAA13345@allegro.lemis.de> from "Greg Lehey" at Nov 26, 95 01:52:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
I thought Peter and I took this offline. It was such an old post he was responding to in the first place. > > > Long doesn't and shouldn't mean "32 bits". > > > > Maybe not. But *something* should mean "32 bits". > > > > The problem is that with a 64 bit int (which, despite your opinion of > > DEC and grandfathering old software, is correct for the Alpha): > > > > int == 64 :== long == 64 > > short == 32 || short == 16 > > char == 8 > > > > You lose access to either 32 bit or 16 bit sized types. > > > > Period. > > You're looking at this from the wrong perspective. Even if you say: > > > ANSI doesn't allow "long long" or "quad". > > That means that ANSI is wrong. If a language doesn't allow you to > access to the primitive data types of your machine, then it's broken. > In the case of C, the answer is obvious enough. ANSI doesn't allow > long long, but that doesn't mean you can't use it. And how about > short short? > > I tend to agree with Peter that it's a good idea to keep data sizes > roughly the same. It may have been a mistake to increase an int from > 16 to 32 bits when moving to the Vax, but that's history. Modern > computers have int lengths which are a power of 2, and that power lies > between 3 and 7 in all cases. Is it really that difficult to find 5 > different descriptions? For example: > > short short 8 bits Uh, some of us call this one "char". 8-). > short 16 > int 32 > long 64 > long long 128 > > I don't think that this should be carved in stone; I'd prefer int8, > int16 etc. for things which really *must* be that length (like data > shared with other architectures), but it would make life a lot easier > if people would adhere to the lengths anyway. Let's clarify my perspective: If there is a type that is treated as atomic (ie: it may be used as the underlying type for off_t according to ANSI and POSIX), then the type promotion has to promote to the largest one allowable. The target promoted type is, in fact, the stack alignment size. This only makes sense, since the stack alignment size and single cycle bus fetch and register sizes dictate the efficiency of the fetch process. This is why Aztec on the Mac and Amiga 68k was correct in setting sizeof(int) == 2 and Lattice (SAS) C was wrong in setting sizeof(int) == 4. An "int" is supposed to be the "natural" type for the machine and take a single bus cycle to load. This satisfies the ANSI C standard, which does not require prototyping of functions, and further specifically allows me to use functions without a prototype in scope. Consider, specifically, "lseek". It is [!>*BOGUS*<!] that I must have a prototype in scope OR must explicitly promote non-quad arguments. Both of these actions are not required of standards conforming code. How much of the pain-in-the-ass of porting something to FreeBSD by programmers who don't voluntarily observe the voluntary writ of faith of having prototypes for everything is caused by off_t? Most of it, I should think. One need not be a Priest or a Nun to be Catholic. One need not use prototypes to produce standards conforming code, though the self appointed Priests would have us act otherwise.. Conforming code should compile and run, even if not written by a religious zealot. This is the whole point of requiring off_t to be an atomic type (which it is NOT in FreeBSD, but which we could consider to be an alias for the atomic type "double" if we were algning our stack correctly right now -- which we are not). size_stack_alignment = MAX( sizeof(atomic_type_1), MAX( sizeof(atomic_type_2), ... MAX( sizeof(atomic_type_n-1), sizeof(atomic_type_n) ) ) ) Even now we are screwing up. The type "double" is atomic, and sizeof(double) == 8. Stack alignment should be 8 bytes. MUST be 8 bytes for 64 bit MIPS processors without an unaligned access exception handler, in any case, since the machine will fail to operate otherwise. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511261922.MAA15217>