Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!prls!pyramid!chronon!eric
From: eric@chronon.UUCP (Eric Black)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: varargs
Message-ID: <237@chronon.chronon.UUCP>
Date: Thu, 1-May-86 14:57:33 EDT
Article-I.D.: chronon.237
Posted: Thu May  1 14:57:33 1986
Date-Received: Sat, 3-May-86 02:11:49 EDT
References: <272@vecpyr.UUCP> <5302@alice.uUCp> <792@ccird2.UUCP> <129@drilex.UUCP> <236@chronon.chronon.UUCP>
Reply-To: eric@chronon.UUCP (Eric Black)
Organization: Chronon Computer Corp., Mtn. View, CA
Lines: 17
Xref: linus net.lang.c:8144 net.unix-wizards:14968

Sorry, but I left out an important point from my previous posting about
vararg difficulties.

My article should in no way be construed as arguing against allowing
a variable number of arguments being passed to a called function.
Rather, it points out that code that *ASSUMES* that varargs are passed
in memory in ascending addresses *IS A HIGHLY MACHINE-DEPENDENT ASSUMPTION*
and is *NOT PORTABLE CODE*.  Library support to handle variable argument
lists in a standardized way is appropriate (see varargs.h on BSD systems
for something which comes very close).  These library routines are quite
simple on a traditional architecture (which is assumed by too many
existing pieces of code -- printf is too many already!).
-- 
Eric Black   "Garbage In, Gospel Out"
UUCP:        {sun,pyramid,hplabs,amdcad}!chronon!eric
WELL:        eblack
BIX:         eblack