🚀 go-pugleaf

In article <434pa4$c4c@news1.wing.net>, pgf@american.com (Paul G. Fox) wrote:
 >hi -- i recently hit a portability problem involving code written
 >using stdarg.h, and i'm wondering if it's me or the vendor that's
 >at fault.
 >
 >the question is this:
 >
 >must the usage of
 >	foo = va_arg(ap, type_of_foo);
 >be confined to the same routine in which the 
 >	va_list ap;
 >and
 >	va_start(ap, last_fixed_arg);
 >expansions occur?

No.  The standard function vsprintf(), which has an ap argument, can
be implemented in strictly conforming C TTBOMK.

 >or, can i pass "&ap" to a lower level routine where it's 
 >declared like this:
 >	va_list *app
 >and used as:
 >	bar = va_arg(*app, type_of_bar) 

The standard to not guarantee that &ap can be passed,  but it does
guarantee that ap itself can be passed.

 >this particular vendor's stdarg.h, however, contains:
 >	typedef char   *va_list[1];
 >instead of the more typical
 >	typedef char   *va_list;

This seems to be a violation of the stipulation that "the object ap
may be passed as an argument to another function..." [ANSI 4.8], since
arrays can't be passed by value.

Although I think the implementation is broken, you should be able to
change your code to pass ap, rather than &ap, and have it work on the
broken one, as well as conforming implementations.

Thad