Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!ut-sally!mordor!jdb From: jdb@mordor.UUCP (John Bruner) Newsgroups: net.unix-wizards,net.lang.c Subject: Re: integer types, sys calls, and stdio Message-ID: <2099@mordor.UUCP> Date: Sun, 13-Jan-85 18:38:10 EST Article-I.D.: mordor.2099 Posted: Sun Jan 13 18:38:10 1985 Date-Received: Tue, 15-Jan-85 01:10:25 EST Distribution: net Organization: S-1 Project, LLNL Lines: 59 Xref: watmath net.unix-wizards:11511 net.lang.c:3871 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@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb