While not denying the validity of the cautions that Mike Westerfield
provided, the technique below seems to work well with the MetroWerks
compiler.  It also seems to work well with the Borland and Microsoft PC
compilers I've tried it with, going back before Standard C to K&R C.

Another caution is that using a variable arguments list in any form is the
opposite of defensive programming as you lose the critical assistance of
function prototypes, and should really be only used when no other technique
makes sense.  And even then try not to use it!

The Marietta PDE (tm) program is currently at 162KB, and I only had to
implement one function like this to support an unstructured search for
records within an ISAM-style Palm OS database that does a caseless match on
one, some or many sub-strings.  There are other techniques, but they seemed
less self-documenting in that one situation and hence more prone to obscure
bugs.

Roger Stringer
Marietta Systems, Inc.

>Date: 10 Nov 1999 21:59:01 -0800
>From: [EMAIL PROTECTED]
>Subject: Re: Variable no of arguments to a function


>In a message dated 11/10/99 7:43:41 PM, [EMAIL PROTECTED] writes:

>>You don't need the macros if all the variable parameters are the same type,
>>for example CharPtr.  This is a very standard C language technique.
>>
>>int foo (int count, CharPtr p1, ...) {
>>        CharPtr *pPtr = &p1;
>>        int i;
>>        for ( i = 0 ; i < count && *pPtr != NULL ; i++) {
>>                CharPtr ptr = pPtr[i];
>>                ......................   // process each parameter in 
>turn....
>>        }
>>        return i;
>>}
>>
>>However, the macros look more elegant, which is one reason they exist.

>The other reason the macros exist is because this isn't legal C. Yes, it's 
>common--but technically, the way the C compiler performs in this situation is 
>left to the discretion of the implementor. Anything, including crashing, is 
>allowed.

>First off, there is no garantee about the way the parameters are stored. Your 
>code explicitly assumes that parameters follow each other in memory in 
>sequential order. This is common, but not required. From the ANSI C standard:

>........
>........

> Mike Westerfield

Reply via email to