Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.lang.c Subject: Re: stdarg Message-ID: Date: 8 Feb 91 01:12:28 GMT References: <588@taumet.com> <1991Feb6.171144.7182@Neon.Stanford.EDU> <1991Feb7.043715.1224@Think.COM> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 39 In-Reply-To: barmar@think.com's message of 7 Feb 91 04:37:15 GMT In article <1991Feb7.043715.1224@Think.COM>, Barry Margolin writes: > In article , Erik Naggum writes: > >How do these functions determine how many arguments to use, and what > >type they are? > Well, consider a function taking a variable number of strings, > followed by a null pointer. The type is known by definition, and > the number of arguments can be determined by looking at them. > I'm not claiming that this is a good programming style, but an awful > lot of people seem to be assuming that a fixed argument is needed in > order to determine how to process the remaining arguments. While > this style could easily be replaced with one where there is an > initial fixed argument containing the count of variable arguments, > that's more prone to error: during program maintenance it is likely > that an argument will be added but the argument count could easily > be left unchanged. You mean char *strmanycat (...) which takes n char * arguments, the last of which being NULL? Since the type of the argument is known, _and_ there has to be at least one argument, why not use char *strmanycat (char *, ...) which could actually use the first argument in the same way it will use the remaining arguments? (Thanks to Mike Taylor at System Simulation, UK, for the example.) I'm left to believe that there is no real use for a (...) construct. -- [Erik Naggum] Naggum Software, Oslo, Norway