Date: Mon, 12 Jan 1998 19:44:29 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brian@awfulhak.org (Brian Somers) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: New typedefs in sys/types.h Message-ID: <199801121944.MAA28476@usr04.primenet.com> In-Reply-To: <199801111544.PAA27565@awfulhak.demon.co.uk> from "Brian Somers" at Jan 11, 98 03:44:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> With the upcoming Alpha stuff, it looks like there are going to be > some problems..... I'm assuming that a `long' is gonna be 64 bits > rather than 32. I don't know about this. Clearly, the u_long should be replaced by u_int32_t; that's a given. But if a long is 64 bits, then what's 32 bits... a short? And if a short is 32 bits, what's 16 bits? 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). The problem is that C fails to have sized types. I'm not sure if the NetBSD/Alpha compiler uses int/long = 64 bits, or uses "long long" (I'm not a home, so it's hard to check; I always used sized types instead of int or long or long long). It sort of points up another dichotomy, though... I guess a 16 bit atomic type could be a short short? Bletch; that's as bad as a 64 bit value being a long long... 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?199801121944.MAA28476>