Date: Mon, 10 Nov 1997 16:22:19 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Archie Cobbs <archie@whistle.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) Message-ID: <Pine.BSF.3.96.971110161334.26189A-100000@darkstar.home> In-Reply-To: <199711102243.OAA00849@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 10 Nov 1997, Archie Cobbs wrote:
> 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>
I understand this, and I plan to weed these things out of libalias (the
only thing I have any responsibility for in the FreeBSD source tree).
However, if you take a cruise the the source tree and even the kernel in
particular, you may discover quite frequent occurences of such problems.
In particular, you might wish to try the following command.
grep long /usr/include/netinet/*.h
Somehow your message came accross as chastising me individually (I
dunderstand these things), when you should consider the entire FreeBSD
code base. What you recommend is good practice, but there is an enormous
amount of existing code which does not adhere to this.
Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971110161334.26189A-100000>