integer types, sys calls, and stdio

[John Bruner]

I'd like to thank everyone who has responded to my inquiry about
integer types, both by posting to these newsgroups and by private
mail.

As I reread my original posting, I realized that I had been a little
obscure about my real intent.  As a former V6 & V7 PDP-11 user/system
maintainer, I'm familiar with the history of the lseek() call and
the reasons why its second argument is not an "int".  (I could tell
you about some of the BSD programs I ported to V7 and the "int"=="long"
assumptions that I had to weed out, but that's another story.)

What I really was trying to ask about was the future direction of
system call (and library routine) interface specifications: were the
machine-specific types of "short", "int", and "long" being supplanted
in these cases by derived types such as "time_t" and "off_t"?  The
derived types would allow a system implementer to choose the most
efficient, sufficiently-large, integer size for each quantity rather
than being saddled forever with decisions made for a PDP-11.

[Several people commented that the correct type for a file offset
is "off_t", not "daddr_t".  Thanks -- it was a case of putting my
keyboard into gear without engaging my brain.]

There seem to be two major points of consensus:

    1)	The use of derived types is preferable, and their use in
	new UNIX versions is increasing.  (I didn't receive any
	replies that specifically mentioned the ANSI C environment
	standard effort, but I assume that the issue is under
	consideration there as well.)  However, there is too much
	code out there which explictly uses "int" and "long" to
	change things quickly.

    2)	The qualifiers "short" and "long" are now pretty generally
	considered to refer to quantities that are roughly 16 and
	32 bits long, respectively.  They can be defined to be
	larger, but this usually just results in a space and
	execution-time penalty.

I'd like to solve our problem with the S-1 Mark IIA by defining the
appropriate derived types as "int"s and making all of our C programs
use the derived types.  Unfortunately, the required conversion effort
would be phenomenal, and we'd have to check all imported programs for
explicit "long" declarations.  This leaves us with two choices.
We will either use the old definitions and suffer the performance
penalty for 72-bit integers where 36-bit ones would suffice
(something I'm not very happy to accept), or we'll redefine "long"
to be the same as "int" and we'll introduce "long long" (something
our C compiler person is reluctant to do).

[BTW, "long long" would have been very useful on the VAX.  It's
a pain to write a cross-assembler for a 36-bit machine when the
largest available integer type is 32 bits wide.]

In any event, I appreciate the help that everyone has offered.
-- 
  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