Subject: Re: C Language Standard(s)
To: Peter Seebach <seebs@solon.com>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: current-users
Date: 12/21/1995 13:38:11
On Thu, 21 Dec 1995 06:32:35 -0600 
 Peter Seebach <seebs@solon.com> wrote:

 > I have little problem with revealing broken software.  NetBSD has already
 > made it clear that it's a designed system, not an end-user system.  :)

Well, we certainly won't score any points by making the change you 
suggest...You're implying that if we do change all longs to 64-bit, it 
makes it basically useless as an end-user system.  I'm sorry, but I'm 
just not prepared to support that stance :-)

 > Also, AFAIK, if we use 32-bit int, and 64-bit long, the only place
 > casting pointers to integers will fail will be a 64-bit pointer environment.

This is exactly why one casts pointers to longs when one is forced (by 
whatever means) to cast a pointer to a non-pointer type.  We're going to 
be seeing _more_ 64-bit systems in the future, and making it harder for 
NetBSD to run on them is definitely _not_ the direction we want to go.

 > In the only 64-bit pointer environment we support that I know of, the
 > standard compiler has already broken that code; OSF/1 uses 16/32/64.
 > 
 > I think this would be a good long-term direction; not something to try
 > to push for an instant conversion of, but add to the coding standards
 > that code outside of machine specifics shall not try to make pointers
 > integers, nor integers pointers, and start periodically cleaning them
 > up.

You're mixing two different issues.  I agree that cleaning up pointer 
casts might be a Good Thing, but it has been said here before that there 
are better things that we can be doing, and it's simply not important 
enough to make it a priority.

It's also been pointed out on this thread that changing longs to 64-bit 
on 32-bit systems would make such a system Really Slow, and the reasons 
for that are _obvious_.

In general, making the `long' type larger than the CPU's "longword" is 
just a Bad Idea.  Can we just put this issue to rest now?

--------------------------------------------------------------------------
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939