home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0051.txt < prev    next >
Encoding:
Text File  |  1990-01-06  |  2.7 KB  |  59 lines
  1. In article <431@longway.TIC.COM> karish@forel.stanford.edu (Chuck Karish) writes:
  2. -In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
  3. ->No, it doesn't -- because "the set of symbols defined by the C standard"
  4. ->can, and must, be construed as permitting all symbols that the C standard
  5. ->specifically reserves for the implementation, including _LOW etc.
  6. -To me, "the set of symbols defined by the C standard" means the set of
  7. -symbols defined, not the set of all possible symbols in some part of
  8. -the name space.  I interpreted this to mean the set of symbols listed
  9. -in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard).  "Defined"
  10. -and "reserved" denote different concepts.
  11.  
  12. But IEEE Std 1003.1 cannot constrain the identifiers reserved for
  13. implementation use by ANSI X3.159.  The intention of this part of
  14. the 1003.1 spec is quite clear -- it means that applications cannot
  15. count on the symbols defined by 1003.1 as being visible in the
  16. Standard C headers unless _POSIX_SOURCE is defined before including
  17. the headers.  It does not impose additional constraints on the pure
  18. X3.159 part of the implementation.  As a practical matter, it cannot
  19. forbid use of the implementation-reserved identifiers, because they
  20. are necessary in many environments in order to correctly implement
  21. X3.159.
  22.  
  23. -This is cleared up somewhat in Drafts 3 and 4 of the P1003.1a
  24. -supplement:
  25. -    2.8.2:  "It is unspecified by this standard whether any symbols in
  26. -    the namespace reserved to the implementation are affected by
  27. -    _POSIX_SOURCE."
  28. -    2.8.2.2:  "If _POSIX_SOURCE is defined ... [s]ymbols from the
  29. -    namespace reserved for the implementation, as defined by the C
  30. -    Standard [1], are also permitted."
  31. -Note that neither of these clauses deals with the case where
  32. -_POSIX_SOURCE is not defined, which is the case I considered in the
  33. -paragraph quoted from my earlier article [2.8.2.1].
  34.  
  35. 2.8.2 obviously DOES deal with the case where _POSIX_SOURCE is
  36. undefined, because it is the contrast between that and the case
  37. where _POSIX_SOURCE is defined that constitutes waht is "affected
  38. by _POSIX_SOURCE".
  39.  
  40. Note that what is defined by the standard headers when _POSIX_SOURCE
  41. is not defined is ENTIRELY specified by X3.159, not by 1003.1.
  42.  
  43. -If the 1003.1 committee means that anything in the implementors'
  44. -name space may be in a header without protection, the standard
  45. -must say so.  As now written, it explicitly says the opposite.
  46.  
  47. You are being deliberately obtuse.  I don't think anybody involved
  48. with drawing up these specifications would back your interpretation.
  49.  
  50. [ Let's avoid personal characterisations and stick to technical points,
  51. please.  -mod ]
  52.  
  53.     - D A Gwyn
  54.     acting X3J11/1003.1 liaison
  55.  
  56. Volume-Number: Volume 17, Number 60
  57.  
  58.  
  59.