home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.std.unix:462 comp.std.c:3022
- Path: sparky!uunet!not-for-mail
- From: steve@taumet.com (Steve Clamage)
- Newsgroups: comp.std.unix,comp.std.c
- Subject: Re: Header files and "hidden built-in type hacks".
- Date: 17 Nov 1992 22:16:56 -0800
- Organization: TauMetric Corporation
- Lines: 34
- Sender: sef@ftp.UU.NET
- Approved: sef@ftp.uucp (Moderator, Sean Eric Fagan)
- Message-ID: <1ecn4oINNp6a@ftp.UU.NET>
- References: <1e6nslINN4rd@ftp.UU.NET>
- NNTP-Posting-Host: ftp.uu.net
- X-Submissions: std-unix@uunet.uu.net
-
- Submitted-by: steve@taumet.com (Steve Clamage)
-
- rfg@netcom.com (Ronald F. Guilmette) writes:
- >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.
-
- ANSI section 4.1.2.1 in conjunction with 4.8 and 4.9 makes it very clear
- that <stdio.h> cannot define the identifier "va_list". It is legal for
- a user program to include <stdio.h> without including <stdarg.h>. If
- <stdarg.h> is not included, the identifier va_list is not reserved.
- Hence hacks like __va_list which are a conforming way around the problem.
-
- >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)?
-
- I can't speak to the POSIX question. Any identifier which is not
- reserved according to 4.1.2.1 and which is implicitly referenced but
- not defined by a Standard C header must have some sort of work-around.
- (Only those identifiers not otherwise reserved may be defined in a
- conforming Standard C header.)
-
- Some types, like size_t, must be defined in more than one header.
- This means that some workaround is needed for these types as well
- to avoid multiple definitions.
- --
-
- Steve Clamage, TauMetric Corp, steve@taumet.com
- Vice Chair, ANSI C++ Committee, X3J16
-
-
- Volume-Number: Volume 29, Number 72
-