Path: utzoo!mnetor!uunet!husc6!hao!ames!lll-tis!elxsi!beatnix!rw
From: rw@beatnix.UUCP (Russell Williams)
Newsgroups: comp.arch
Subject: Re: Re: More than 32 bits needed where?
Message-ID: <711@elxsi.UUCP>
Date: 19 Feb 88 21:42:34 GMT
References: <235@unicom.UUCP> <28200089@ccvaxa> <3104@watcgl.waterloo.edu> <4340@ames.arpa> <1333@vaxb.calgary.UUCP> <41350@sun.uucp> <9495@steinmetz.steinmetz.UUCP> <4679@ames.arpa> <3671@diku.dk>
Sender: nobody@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 17

In article <3671@diku.dk> keld@diku.dk (Keld J|rn Simonsen) writes:
>
>There is a problem with C that long ints are usually not more
>than 32 bits, even if the hardware is capable of doing 64 bits
>adds and subtracts. This I foresee to cause severe problems for
>C-based accounting software! Comments?
>
   We tried making longs 64 bits and lots of programs wouldn't run, so
we put int=long=32 bits and added a "long long" type.  Another example
of common practice along the lines of dereferencing null pointers.  
Customers don't like being told their programs are non-portable ("fine,
I'll buy a Vax"), and of course we're stuck with fixing the AT&T and
Berkeley code.  In the real world the portability of a C program is
not really defined by K&R but by what a Vax running Unix does.

Russell Williams
..uunet!elxsi!rw