va_list used in <stdio.h>

[Steve Summit]

Last night I posted a long article exploring the impossibility
of writing a standalone stdio.h, that is, one that does not not
somehow "know" the underlying type of a va_list without
#including <stdarg.h>.  Doug Gwyn is about to post an article
saying that allowing standalone reimplementation of parts of the
C run-time library was never an X3J11 requirement, and I'm sure
that's true, but I don't have to like it.  In fact, there is a
way out of this particular dilemma, although it's too late now.

The essential problem is the requirement that <stdio.h> contain
prototypes for vprintf, vfprintf, and vsprintf.  The v*printf
family are "crossover functions:" they combine functionality from
the stdio and stdarg (nee varargs) subportions of the library.
In languages with more formal type and class concepts, explicit
means are often required to implement such crossover functions,
such as the "friend" function notation of C++.

A solution would have been to acknowledge the special nature of
the v*printf by putting them in their own header file, vprintf.h:

	#include <stdio.h>
	#include <stdarg.h>

	extern int vprintf(char *, va_list);
	extern int vfprintf(FILE *, char *, va_list);
	extern int vsprintf(char *, char *, va_list);

In general, I'd have preferred it if X3J11 had been somewhat more
granular in their assignment of new header files.  As another
example, it would be convenient if malloc, realloc, and free were
in a <malloc.h> rather than lumped in with everything else in
<stdlib.h>.  (This could make it easier for implementors of
debugging versions of malloc, intended to replace or sit atop
the vendor-supplied one.)

I realize that picking the right header file granularity involves
tradeoffs.  There are probably programmers who dislike having to
#include everything under the sun and would prefer an opposite
extreme, something along the lines of <libc.h> or <everything.h>.
Many of my source files start out with 15 or 20 #include
directives, and while this may not be ideal, I much prefer the
flexibility that finer granularity affords.

                                            Steve Summit
                                            scs at adam.pika.mit.edu