From owner-freebsd-hackers Mon Nov 10 15:23:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA07234 for hackers-outgoing; Mon, 10 Nov 1997 15:23:02 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from srv.net (snake.srv.net [199.104.81.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA07224 for ; Mon, 10 Nov 1997 15:22:58 -0800 (PST) (envelope-from cmott@srv.net) Received: from darkstar.home (tc-if3-35.ida.net [208.141.171.140]) by srv.net (8.8.7/8.8.5) with SMTP id QAA32319; Mon, 10 Nov 1997 16:22:53 -0700 (MST) Date: Mon, 10 Nov 1997 16:22:19 -0700 (MST) From: Charles Mott X-Sender: cmott@darkstar.home To: Archie Cobbs cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Newest Pentium bug (fatal) In-Reply-To: <199711102243.OAA00849@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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. > > > > 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! > > 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