Date: Mon, 10 Nov 1997 14:43:54 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: cmott@srv.net (Charles Mott) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) Message-ID: <199711102243.OAA00849@bubba.whistle.com> In-Reply-To: <Pine.BSF.3.96.971110125152.25875B-100000@darkstar.home> from Charles Mott at "Nov 10, 97 01:01:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Mott writes: > > Perhaps if the source tree were reorganized to be more multiple > > architecture friendly, progress would speed up? > > I'm sure other people have seen this problem, but the long data > type seems to cause hell when transitioning from 32 to 64 bit > architectures. There seem to be 2 strategies: > > (1) int = 32 bits, long = 32 bits, long long = 64 bits > > (2) int = 32 bits, long = 64 bits > > Strategy (1) helps with a lot of the networking code which assumes long is > 32 bits, but then there are some functions which seem to think that the > long data type should be the same size as an absolute address pointer. > > If int ever goes to 64 bits, I can't imagine what disasters would be > waiting. But the fact that the NetBSD and OpenBSD people must have dealt > with this problem indicates there must be a straightforward solution. <nitpicking> This brings up a good point... if you're writing code and you want/expect something to be 32 bits, then its type should be either "int32_t" or "u_int32_t"!! Same goes for 8, 16, and 64! </nitpicking> -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711102243.OAA00849>