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