Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!cit-vax!news
From: news@cit-vax.UUCP
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: Time for 64-bit longs?
Message-ID: <1743@cit-vax.Caltech.Edu>
Date: Tue, 10-Feb-87 02:13:30 EST
Article-I.D.: cit-vax.1743
Posted: Tue Feb 10 02:13:30 1987
Date-Received: Wed, 11-Feb-87 05:37:10 EST
References: <848@epimass.UUCP> <291@mtxinu.UUCP> <1643@cit-vax.Caltech.Edu> <263@elxsi.UUCP>
Reply-To: jon@oddhack.UUCP (Jon Leech)
Organization: California Institute of Technology
Lines: 29
Xref: watmath comp.lang.c:982 comp.unix.wizards:902

Organization : California Institute of Technology
Keywords: 
From: jon@oddhack.Caltech.Edu (Jon Leech)
Path: oddhack!jon

In article <263@elxsi.UUCP> sherm@elxsi.UUCP (Michael Sherman) writes:
>In article <1643@cit-vax.Caltech.Edu> I write:
>>Why not have
>>short=16 bits, int=32 bits, long=64 bits?
>
>When we began our first Unix port to the ELXSI we tried your suggestion
>and found that it was actually *rare* to find a program that would still
>work with 64-bit longs.  

	I remember that. All of MY programs worked ok :-)

>
>After repeatedly bashing our heads against horrible debugging problems in 
>third-party's 100,000 line applications we finally saw the light and 
>switched to a 32-bit long and a 64-bit long long.
>
>Moral arguments aside, we're stuck with int==long.

	Moral arguments aside, int != long on most 80x86 and some 68000
implementations. I think what you're really stuck with is long == 32 bits.

    -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon)
    Caltech Computer Science Graphics Group
    __@/