Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: var args
Message-ID: <3272@utzoo.UUCP>
Date: Fri, 21-Oct-83 17:51:13 EDT
Article-I.D.: utzoo.3272
Posted: Fri Oct 21 17:51:13 1983
Date-Received: Fri, 21-Oct-83 17:51:13 EDT
References: <3637@duke.UUCP>, <3258@utzoo.UUCP>, <338@wjh12.UUCP>
Organization: U of Toronto Zoology
Lines: 30

I'm not so much *objecting* to the machine-dependent nature of
variable-length-arg-list routines, as trying to point out that
their implementation *is* fundamentally machine-dependent and
there is *no* *way* *around* *this*.  This is in response to
numerous people proposing one notion after another of how to do
something that simply cannot be done.  Worse, some of their schemes
do work on *some* machines, and people who don't understand the
messiness of the issue might assume that they work everywhere.
I've had enough encounters with unportable software as a result of
such assumptions to think it worthwhile to try to head this particular
problem off.

Yes, I'm aware of the library packages under 4BSD and System V that
try to at least bury the machine-dependencies in a library.  Be warned
that even they don't suffice on sufficiently bizarre machines.

The most common reason for wanting vararg routines other than the
standard ones is a desire to write an error-handling routine that
puts out a printf-style message and then does some program-dependent
cleanup actions.  The *only* 100% portable way to do this is:

	sprintf(buf, ".....", ....);
	error(buf);

I know it's a nuisance to do two calls instead of one, and the need
to have a buffer variable is annoying, but this code is guaranteed
to be fairly portable, while using %r, _doprnt, &args, etc. is not.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry