Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sfmag.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!sfmag!mjs
From: mjs@sfmag.UUCP (M.J.Shannon)
Newsgroups: net.lang.c
Subject: Re: (Guy) HARRIS FLAME Re: SHORT vs. INT
Message-ID: <687@sfmag.UUCP>
Date: Wed, 11-Sep-85 09:26:26 EDT
Article-I.D.: sfmag.687
Posted: Wed Sep 11 09:26:26 1985
Date-Received: Thu, 12-Sep-85 12:20:24 EDT
References: <1390@brl-tgr.ARPA>
Organization: AT&T Information Systems, Summit, NJ
Lines: 21

> 2.  NETWORK COMMUNICATION
> To enable network communication between different machines, a "short" is
> guaranteed to be 16-bits and a "long" is guaranteed to be 32-bits.  This
> is either convention or standard, I am not sure which.

The C language guarantees only that "short" is no longer than "long".  There
is no guarantee of any width of "short", "int", or "long" other than that!
It does turn out that in most implementations, the underlying hardware gives
the compiler-writer a choice of 8-, 16-, 32-, and possibly 64-bit integers,
but there are notable exceptions: the Honeywell 6000 (since renamed, but I
no longer recall what the new name of that architecture is), the DECsystem
10 & 20, etc.  These machines don't have word sizes that are powers of 2
wide (in bits).  Rather, a word is 36 bits wide, a halfword is 18, and a byte
is just about any size you like (5, 6, 7, 8, 9 bits).  Folks who depend on
integral types having exactly some size write less portable code than folks
who depend on said types having at least some size.
-- 
	Marty Shannon
UUCP:	ihnp4!attunix!mjs
Phone:	+1 (201) 522 6063
Disclaimer: I speak for no one.