home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0074.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  2.0 KB  |  48 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <1e6nslINN4rd@ftp.UU.NET> 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.  
  7. Absolutely -- an implementation that defines the identifier "va_list" as
  8. a side effect of the inclusion of <stdio.h> does not conform to the C
  9. standard.
  10.  
  11. >My second question is also a simple one.  In what other cases are such
  12. >"hidden built-in type hacks" required as a result of other requirements
  13. >in the ANSI C standard (or in POSIX 1003.1-1990)?
  14.  
  15. The most common issue is how to typedef e.g. size_t in multiple headers.
  16. This requires some sort of "one-time conditional lock", for example
  17.     #ifndef __SIZE_T_DEFINED
  18.     #define __SIZE_T_DEFINED
  19.     typedef unsigned size_t;
  20.     #endif
  21. in each header that is required to provide a declaration of size_t.
  22.  
  23. >even though section 4.12.1 (describing <time.h>) does not seem to permit
  24. ><time.h> to define the size_t type.
  25.  
  26. To the contrary, 4.21.1 specifies that size_t IS declared by <time.h>
  27. (X3.159-1989 p.171 l.12).
  28.  
  29. >My second observation is that it appears that another such case arises
  30. >for those who wish to implement strict conformance with POSIX 1003.1-1990.
  31.  
  32. I can't help much with that.  Note that the POSIX.1 headers need to
  33. interoperate with the standard C headers, which implies more use of
  34. one-time conditional locks etc.  Of course, the standard C headers
  35. exhibit some POSIX additions when included in the context of the
  36. _POSIX_SOURCE feature-flag macro.  (This was necessitated to support
  37. existing UNIX practice -- it is NOT recommended that future standards
  38. specify more changes to the standard headers!  For one thing, the
  39. parties responsible for the standard C+POSIX.1 implementation may not
  40. be the same parties as those who have to provide the additional
  41. implementation, for example a graphics library.  And in any case
  42. the use of "feature flag" macros makes a mess of the headers that
  43. adds to maintenance woes.)
  44.  
  45.  
  46. Volume-Number: Volume 29, Number 74
  47.  
  48.