Xref: utzoo comp.lang.c:20823 comp.std.c:1539 Path: utzoo!utgpu!watmath!att!ucbvax!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs From: scs@adam.pika.mit.edu (Steve Summit) Newsgroups: comp.lang.c,comp.std.c Subject: Re: va_list used inSummary: header file granularity Keywords: va_list, X3J11, vfprintf, header files Message-ID: <13574@bloom-beacon.MIT.EDU> Date: 17 Aug 89 14:09:38 GMT References: <1140@midgard.Midgard.MN.ORG> <10720@smoke.BRL.MIL> <2095@dataio.Data-IO.COM> <10739@smoke.BRL.MIL> <13572@bloom-beacon.MIT.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Lines: 45 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 . 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 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 #include 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 rather than lumped in with everything else in . (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 or . 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@adam.pika.mit.edu