Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!oliveb!jerry
From: jerry@oliveb.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Supercomputer Unix decisions (really type sizes)
Message-ID: <1893@oliveb.UUCP>
Date: Wed, 8-Jul-87 16:59:03 EDT
Article-I.D.: oliveb.1893
Posted: Wed Jul  8 16:59:03 1987
Date-Received: Sat, 11-Jul-87 14:11:44 EDT
References: <3659@spool.WISC.EDU> <743@geac.UUCP> <4679@columbia.UUCP> <420@elxsi.UUCP> <1124@copper.TEK.COM> <12670@topaz.rutgers.edu>
Reply-To: jerry@oliveb.UUCP (Jerry F Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 23

In article <12670@topaz.rutgers.edu> hedrick@topaz.rutgers.edu (Charles Hedrick) writes:
>Unfortunately in C (as most other languages) there is no distinction
>between how you describe variables to be used within your program and
>how you describe external objects.  The result is that network code
>and code that handles records on tapes, etc., is full of descriptions 
>that use char, short and long, to refer to 8, 16, and 32 bit
>quantities.  Frankly I think this is a mistake.  I think we should
>have a separate way of declaring external objects that is independent
>of the machine's byte order, word size, etc.  But at the moment there

The inability to precisly specify type sizes is a bad limitation of C.
As a practacal work around some code will either define or typedef
int16 and int32 values in an include file.  These can be used thruout
the program and only the include file needs to be changed when porting.

This is a common enough problem that all versions of unix should have a
standard include file that defines the various size values more
precisely.  Also nice would be the ability to specify at least N bits
but round up to the next largest size.

I am not a fan of Pascal but it does handle this a little better than C.

					Jerry Aguirre