Can anyone find a system on which this doesn't work?

[Jeff Lee]

> In article <4669 at utzoo.UUCP>, henry at utzoo.UUCP writes:
> 
> > There exist machines on which <varargs.h> is unimplementable.
> 
> I'd be very interested in some specific examples.  Machines
> already running UNIX, please, or likely to run it: not
> antiques.
> 
> John Mackin, Physiology Department, University of Sydney, Sydney, Australia
> ...!decvax!mulga!physiol.su.oz!john

In a C compiler that was implemented on our Primes, the only way to provide
it was to have the <varargs.h> package declare as many arguments as (hopefully)
would ever be used and hope that was enough. I think this is a hack. It works
(barely) but if any other machines have any more restrictions then it would be
impossible. The problem is that procedure entry handles the stack allocation
for you (thanks a lot). It has the number of parameters is kept in the entry
control block and it will not transfer any more arguments than are accounted
for in the control block. This is actually more serious than it may seem,
because the parameter pointers are kept in procedure space following the
procedure call which means that the return program counter (not accessible,
really) is not bumped past the arguments and you end up executing data
pointers. Ok, so we can allocate a possible 50 arguments (we actually use 10)
but then you run into the problem that it takes 2.4 microseconds per actual
argument EXPECTED (on a P400, past the initial 12.6 microseconds for the PCL).
This makes those calls seem REAL LONG. The result is that <varargs.h> is
supplied but you pay for it and it isn't a general purpose facility.

-- 
Jeff Lee
CSNet:	Jeff @ GATech		ARPA:	Jeff.GATech @ CSNet-Relay
uucp:	...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff