🚀 go-pugleaf

Submitted-by: rfg@netcom.com (Ronald F. Guilmette)

As the regular readers of comp.std.c are probably aware, there is a
rather strange set of (seemingly conflicting) requirements with regard
to the declaration of certain implementation-defined primitive data types
and certain header files.

The most commonly cited example is the type `va_list' and the <stdio.h>
header file.

Certain of the functions which must be declared (preferably with prototypes)
in the <stdio.h> file (e.g. vprintf) are defined (by the ANSI C standard) to
take arguments of type `va_list'.  So if these function are declared (using
prototypes) within <stdio.h> it seems (at first glance) that the implementa-
tion must arrange to have the type `va_list' be declared whenever <stdio.h>
is included into any compilation unit.

But careful implementors know that if `va_list' is declared whever <stdio.h>
is included, this will cause an small but unnecessary (and possibly illegal)
pollution of the user's namespace.  Thus, careful implementors always make
use of some *other* symbol (e.g. __va_list or __builtin_va_list) as the
formal type given for the "va_list" type parameters in the prototyped
function declarations in <stdio.h>.

I have two questions about this practice, and two follow-up observations.

My first question is simply this.  Is the practice of avoiding definition
of a va_list type in <stdio.h> strictly required by the ANSI C standard?
My (naive?) believe is that this practice *is* required in order to avoid
non-standard pollution of the user's namespace.

My second question assumes that the answer to the first question is "yes".

My second question is also a simple one.  In what other cases are such
"hidden built-in type hacks" required as a result of other requirements
in the ANSI C standard (or in POSIX 1003.1-1990)?

My first observation is that it appears that another "hidden built-in type
hack" (similar to the one for va_list and <stdio.h>) is also required in
the case of the <time.h> file, where the ANSI C standard requires that the
second formal parameter for the `strftime' function have type `size_t'
even though section 4.12.1 (describing <time.h>) does not seem to permit
<time.h> to define the size_t type.

My second observation is that it appears that another such case arises
for those who wish to implement strict conformance with POSIX 1003.1-1990.
Sepcifically, while POSIX 1003.1-1990 seems to require that <sys/types.h>
be included prior to <sys/stat.h>, certain of the things which must be
declared within <sys/types.h> (under the rules of POSIX 1003.1-1990) must
have type `time_t' even though neither <sys/stat.h> nor <sys/types.h> are
required (by POSIX) to define such a type.

(Footnote:  I know that POSIX 1003.1-1990 explicitly permits <sys/types.h>
to contain additional type declarations above and beyond those which are
minimally required to appear there, but there are some implementors who
are fanatics about the avoidance of arbitrary implementation-dependent
bits of namespace pollution, and I can well imagine that such implementors
would wish to use one of these "hidden built-in type hacks" for the
`time_t' type in <sys/stat.h>.  Now I just want to now if the rules permit
them to do that, and if they should be encouraged to do it.)

-- 

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.


Volume-Number: Volume 29, Number 70