Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!uupsi!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Is va_list defined by <stdio.h>?
Message-ID: <15830@smoke.brl.mil>
Date: 15 Apr 91 22:11:47 GMT
References: <16965@hoptoad.uucp> <15781@smoke.brl.mil> <11982@dog.ee.lbl.gov>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 34

In article <11982@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>Indeed?  And how do *you* propose to implement <stdio.h> such that it
>is machine independent, yet meets all the constraints imposed by both
>ANSI and POSIX?

The obvious solution is:
	/* stdio.h: */
	#include <sys/config.h>	/* defines __* types (only) */
	extern int vprintf(const char *,__va_list);
	/* etc. */

	/* stdarg.h: */
	#include <sys/config.h>	/* defines __* types (only) */
	#define	va_list	__va_list
	/* etc. */

	/* sys/config.h: */
	#ifndef __CONFIG_H_INCLUDED
	#define	__CONFIG_H_INCLUDED
	typedef char *__va_list;	/* or whatever is required */
	/* other typedefs here */
	#endif

I believe some implementors are using one such typedef-file per
standard typedef, but I would suggest having just ONE header file
that requires proper configuration when porting the implementation.
(You could try to automatically tailor this configuration file, but
I personally would prefer to edit it manually so that I could be
sure of the choices being made.)

This may not be too far from what your <machine.h> does.  You need
to be careful not to introduce spurious nonreserved identifiers into
the standard headers, which is why I show only __* names in the
system-configuration header.