[OT] additional parameter before va_alist

[Jun Woong]

Sorry, this might be completely OT, since it's about pre-standard C.

As I know, it was very hard to encount a pre-standard implementation
for the following construct to cause a problem:

#include <varargs.h>

func(fmt, va_alist)
va_dcl
{
/* ... */
}

Then, what was the reason that many experts of pre-standard
implementations here kept saying "don't put an additional parameter
name before va_alist?" It's not that I'm claiming that the above code
was perfectly correct, I ask this just because of curiosity.

Thanks in advance.

 

[Dan Pop]

Sorry, this might be completely OT, since it's about pre-standard C.

Pre-standard C is topical here.

As I know, it was very hard to encount a pre-standard implementation
for the following construct to cause a problem:

#include <varargs.h>

func(fmt, va_alist)
va_dcl
{
/* ... */
}

Then, what was the reason that many experts of pre-standard
implementations here kept saying "don't put an additional parameter
name before va_alist?" It's not that I'm claiming that the above code
was perfectly correct, I ask this just because of curiosity.

Because this is what the documentation of <varargs.h> said:

DESCRIPTION

This set of macros allows portable procedures that accept
variable argument lists to be written. Routines that have
variable argument lists (such as printf(3C)) but do not use
varargs are inherently non-portable, as different machines
use different argument-passing conventions.

va_alist is used as the parameter list in a function header.
^^^^^^^^^^^^^^^^^^

va_dcl is a declaration for va_alist. No semicolon should
follow va_dcl.

This basically means that a variadic function using <varargs.h> must be
defined like this:

void foo(va_alist)
va_dcl
{
/* ... */
}

The words "the parameter list" underlined above don't leave any room
for other parameters.

It's basically the same issue as void main() in standard C programs: it
"works" by accident on most implementations, but without any guarantees
and there are (or may be) implementations where it doesn't work at all.

Since this is a pre-standard issue, one can't call it undefined behaviour,
but it's the same thing.

Dan