Date: Tue, 13 Jan 1998 00:27:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: avalon@coombs.anu.edu.au (Darren Reed) Cc: tlambert@primenet.com, brian@awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: New typedefs in sys/types.h Message-ID: <199801130027.RAA25349@usr08.primenet.com> In-Reply-To: <199801122348.QAA03571@smtp01.primenet.com> from "Darren Reed" at Jan 13, 98 10:48:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Technically, long should be 64 bits because sizeof(int) is <= sizeof(long); > > but just as technically, a 64 bit int meets the "register size test" > > and the "single bus cycle test" for "int-ness" (the same test that > > *should* have made compiler writers use 16 bit int's on 68000/68010 > > chips). [ ... ] > i believe i goes like... > > long = 64 bits > int = 32 bits This is, of course, just the bogosity I was trying to avoid. The sizeof(int) on an Alpha should clearly be 64 bits *unless* the sizeof(long) was 32 bits, since sizeof(int) <= sizeof(long). This is pretty obvious because an int is the "natural" size for the processor; by implication: 1) An int is the largest type that may be fetched or stored in a single bus cycle 2) An int is the size of the largest atomically readable internal register People who believe #1 made 68000/68010 ints 16 bits because of data bus width. People who believe #2 made 68000/68010 ints 32 bits because of the register size. Both of these people would make Alpha ints 64 bits. When you define int as 32 bits here, you're doing it as a convenient way of jamming a different atomic sized type in without having to define a new atomic type to do it. It's a cop-out. While we are at it, we should consider the impact on the following: XDR RPC DCE RPC Structure Packing (Intra-structure Padding) Array Of Structure Packing (Inter-structure Padding) htonl()/ntohl() htons()/ntohs() etc. Picking a "magic" value for "int" to keep access to an atomic type that becomes inacessable because the language definition is obsolete, or because POSIX mandates atomic types (off_t, anyone?) is a Bad(tm) idea, and one that has been hashed through before... The reason we have to have prototypes in scope is because the compiler fails to promote to the largest atomic type for passing. You could argue that there is an assumption about sizeof(int)==sizeof(long) in the compiler because of this. The 68000/68010 Aztec C compiler (from Manx) did not have this assumption. Regardless, even if the assumption is wrong, there's no need to correct it at this time because we bit the bullet on off_t using prototypes needing to be in scope for off_t values to be used. Even if we had solved this by making 64 bits the "natural" size for passing (as we *should* have), it's irrelevent, since the "natural" sizeof(int) on an Alpha is 64... > short = 16 bits > char = 8 bits > > and of course... > > void * = 64 bits > > Of course, wherever size matters, you should be using u_int32_t or > u_int16_t or u_int64_t. Frankly, I do not know what "short" should be. It is only clear to me that "int" should be 64 bits if long is 64 bits or larger, and so allows int to be larger. I *do* agree that we need 16 and 32 bit sized types; I have no idea how they should be implemented. If it weren't for the fact that there is also a need for an 8 bit sized type, I'd be tempted to suggest that char's should be 16 bits (at least it would get rid of that abomination before God of wchar_t as seperate from char, and all "char *p; p++;" using code would instantly become "16 bit Unicode clean"; then locales are a matter of nothing more than data and input methods for a round trip character set). A bit frustrated, 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?199801130027.RAA25349>