integer types, sys calls, and stdio

[John Bruner]

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.

Well, not quite.  There is a lot of confusion in UNIX source code
about the types of integers which are passed as arguments to
system calls or "stdio" routines.  Anyone who has tried to port
a program written for a VAX where long==int to a machine like the
PDP-11 is familiar with the problem.  Worse yet, the descriptions
of the system calls in chapter 2 of the UPM reflect this: 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.

Does System V define system calls using derived types?  Will the
C environment standard define "stdio" routines using derived types?
If so, I'd like to follow those standards.

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.
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb at mordor.ARPA [jdb at s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb