home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0071.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.5 KB  |  36 lines
  1. Submitted-by: steve@taumet.com (Steve Clamage)
  2.  
  3. rfg@netcom.com (Ronald F. Guilmette) writes:
  4. >My first question is simply this.  Is the practice of avoiding definition
  5. >of a va_list type in <stdio.h> strictly required by the ANSI C standard?
  6. >My (naive?) believe is that this practice *is* required in order to avoid
  7. >non-standard pollution of the user's namespace.
  8.  
  9. ANSI section 4.1.2.1 in conjunction with 4.8 and 4.9 makes it very clear
  10. that <stdio.h> cannot define the identifier "va_list".  It is legal for
  11. a user program to include <stdio.h> without including <stdarg.h>.  If
  12. <stdarg.h> is not included, the identifier va_list is not reserved.
  13. Hence hacks like __va_list which are a conforming way around the problem.
  14.  
  15. >My second question is also a simple one.  In what other cases are such
  16. >"hidden built-in type hacks" required as a result of other requirements
  17. >in the ANSI C standard (or in POSIX 1003.1-1990)?
  18.  
  19. I can't speak to the POSIX question.  Any identifier which is not
  20. reserved according to 4.1.2.1 and which is implicitly referenced but
  21. not defined by a Standard C header must have some sort of work-around.
  22. (Only those identifiers not otherwise reserved may be defined in a
  23. conforming Standard C header.)
  24.  
  25. Some types, like size_t, must be defined in more than one header.
  26. This means that some workaround is needed for these types as well
  27. to avoid multiple definitions.
  28. -- 
  29.  
  30. Steve Clamage, TauMetric Corp, steve@taumet.com
  31. Vice Chair, ANSI C++ Committee, X3J16
  32.  
  33.  
  34. Volume-Number: Volume 29, Number 72
  35.  
  36.