From owner-freebsd-hackers  Mon Nov 10 14:45:08 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id OAA05258
          for hackers-outgoing; Mon, 10 Nov 1997 14:45:08 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA05242
          for <freebsd-hackers@FreeBSD.ORG>; Mon, 10 Nov 1997 14:44:52 -0800 (PST)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id OAA20090; Mon, 10 Nov 1997 14:44:17 -0800 (PST)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma020086; Mon Nov 10 14:43:54 1997
Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id OAA00849; Mon, 10 Nov 1997 14:43:54 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <199711102243.OAA00849@bubba.whistle.com>
Subject: Re: Newest Pentium bug (fatal)
In-Reply-To: <Pine.BSF.3.96.971110125152.25875B-100000@darkstar.home> from Charles Mott at "Nov 10, 97 01:01:28 pm"
To: cmott@srv.net (Charles Mott)
Date: Mon, 10 Nov 1997 14:43:54 -0800 (PST)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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