Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: Is va_list defined by <stdio.h>?
Message-ID: <11982@dog.ee.lbl.gov>
Date: 11 Apr 91 04:25:22 GMT
References: <16863@hoptoad.uucp> <11852@dog.ee.lbl.gov> <16965@hoptoad.uucp> <15781@smoke.brl.mil>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 47
X-Local-Date: Wed, 10 Apr 91 21:25:22 PDT

>In article <16965@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>>I believe that ANSI C should not have forced us to introduce these two
>>new problems.  In other words, this is a botch in the standard, that
>>should be fixed in its next revision.  Preferably the fix will simply
>>permit <stdio.h> to define va_list, or indeed, for it to include
>><stdarg.h>, so that no backdoor monkeyshines at all would be needed.

In article <15781@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>Many of the top C experts in the world disagreed with you.
>I think the standard has this exactly right.

The standard tries to make things easy for users, and makes things hard
for implementors in the process.  Whether this is a Good Thing depends
on whether you are a user or an implementor (and on whether you can get
your job done using only the facilities provided in X3.159-1989, or
whether you must use additional types, object, and functions).

>However, it does look like 4.4BSD has an awkward implementation.
>That's not the fault of the standard.

Indeed?  And how do *you* propose to implement <stdio.h> such that it
is machine independent, yet meets all the constraints imposed by both
ANSI and POSIX?  (If you want to make stdio.h machine dependent, my
reply is unprintable.)  Remember that the goal is to have 4.4BSD run
on:

	vax
	tahoe
	hp9000/300 (68020/030)
	intel 80386 (in as little as 640k!)
	mips (both big- and little-endian, i.e., decstations too)
	sparc

and anything else we can trick anyone into doing :-) (HP-PA and 88000
would be nice).  All of these are to be built from a single source.  We
are not there yet (only the first four have ever been integrated
together in one place, and some of the systems are not yet running),
but even four disparate platforms is tricky.

(Note that when I say `from the same source', I mean it: you can
NFS-mount /usr/src read-only, log on to all the different machine
types, and run `cd /usr/src; make' on all of them simultaneously.  Then
you can take bets on which one will finish first....)  (The binaries
are put in per-machine directories in /usr/obj, via symlinks.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov