integer types, sys calls, and stdio

[Ed Gould]

> Here at the S-1 Project at LLNL we are porting UNIX to our own
> machine, the S-1 Mark IIA.  The hardware is capable of operating
> upon 9-bit, 18-bit, 36-bit, and 72-bit quantities, so we have
> defined the following types:
> 
> 	char	= 9 bits	(S-1 quarterword)
> 	short	= 18 bits	(S-1 halfword)
> 	int	= 36 bits	(S-1 singleword)
> 	long	= 72 bits	(S-1 doubleword)
> 
> So far, so good.
>
> ...
>
> One final recourse for us would be to admit defeat, change "long"
> to 36-bits, and hack in a "long long" type for 72-bit integers.  I
> don't want to do this, because it means that while the definition of
> integer types is machine dependent, the machine that they depend upon
> is the PDP-11 or the VAX.

Please DO!  The definition of C calls for *two* lengths of integers:
"short int" and "long int".  "int" alone may be defined as one or the
other.  Actually, the other approach you could take is "short short int"
for the 18-bit ones, using "short int" for 36 and "long int" for 72.
This is what the folks at Amdahl finally did with their UTS port.
I tried porting stuff from the VAX to their pre-release that had
16-bit shorts, 32-bit ints, and 64-bit longs and wound up
#defining long to int, but that didn't work either.


>                                                           in V7
> "lseek" is defined as
> 
> 	long lseek(fildes, offset, whence)
> 	long offset;
> 
> whereas in the 4.2BSD manual it is
> 
> 	pos = lseek(d, offset, whence)
> 	int pos;
> 	int d, offset, whence;
> 
> I consider the 4.2BSD definition to be wrong.  My question is: should
> I consider the V7 definition to be correct?
> 
> We can define our system calls to use "int" and "long" integers as
> V7 does, but this means that we'll have to use 72-bit integers when
> a 36-bit integer would nearly always suffice.  This seems ugly to me.
> In addition, it imposes a size and speed penalty.
> 
> An alternate definition might be:
> 
> 	daddr_t lseek(fildes, offset, whence)
> 	daddr_t offset;
> 
> where "daddr_t", defined in <sys/types.h>, is machine-dependent.

The issue of how to name system-dependant types (e.g., daddr_t) is
separate from the types defined by the compiler.  You're right that
4.2 defines them wrong - they should have used daddr_t and off_t.
It's ususlly clear what the right width is; it should be named in
the most portable way possible.  Usually this means using either
long or short, never int.  Int is supposed to be the "natural"
length for the machine, and presumably it's the fastest form.
It should be used when the width of the item isn't too important
and where, for portability, 16 bits is *always* enough.
(Actually, I think the definition should be

	off_t lseek(...)
	off_t offset;

using offset, not disk addresses.)

-- 
Ed Gould		    mt Xinu, 739 Allston Way, Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146