🚀 go-pugleaf

In article <BxAL1r.J3r@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
| In article <1992Nov6.014500.1353@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
| >In other words, may a programmer safely assume that invocations (or
| >expansions) of va_start and va_end are themselves expressions?
| >The function declarations shown in 4.8.1.1 and 4.8.1.2 seem to suggest
| >that the answer is yes.
| 
| 4.8.1, page 123 lines 17 to 19, says that va_start and va_arg must
| be macros, while va_end may be either macro or identifier.  However,
| if we interpret the function declarations as specifying usage syntax,
| then I would say that they must be expressions, as you say.
| 
| The va_list ap; declaration must be moved inside the function.
| 4.8, page 123 lines 11 to 12.  Ah wait a minute.  The function has to
| have this declaration, not necessarily a definition.  So you can keep
| the file scope one (with external linkage at that) and just copy it
| into the function as well.  I wonder if this is a bug (different rule
| from what was intended) in the standard.

Past practice on a Pyramid in the (partially) related varargs.h was
that va_end was simply a closing brace, while va_start was some gnarly
stuff with an extra opening brace.  I guess they relied on people
putting va_start and va_end in the right places, matching them
appropriately, and always requiring the va_end, which some lazy people
leave out on many architectures.  Pyramid have changed this now.

I certainly would never expect to use va_start and va_end other than
as equivalents of statements, unless I knew chapter and verse of the
standard which said explicitly that it was okay to treat them as
expressions.  Even then, not until all my obsolete machines go away...

Since Pyramid will apparently never ship a stdarg.h for the machine
I'm using, despite shipping a compiler which groks (some?) prototypes,
I'll never know.

-- Christopher

Disclaimer: I can't even afford a copy of the standard.  Either one.