home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0126.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.5 KB
  1. From:  karish@mindcrf.uucp
  2.  
  3.  
  4. In article <9997@cs.utexas.edu> std-unix@uunet.uu.net writes:
  5. >From:  jms@apple.com (John Michael Sovereign)
  6. >In article <9951@cs.utexas.edu> jason@cnd.hp.com (Jason Zions) writes:
  7. >
  8. >> This makes the assumption that there is indeed a single POSIX name space,
  9. >> to which pieces are added by the various working groups. This assumption,
  10. >> while a reasonable one, is in fact not correct.
  11. >
  12. >There is, however, a single C language name space which new standards (and 
  13. >revisions)
  14. >pollute as long as they continue to use header files already defined by 
  15. >ANSI C and/or POSIX.1
  16. >(as I believe Doug Gwyn pointed out recently).
  17.  
  18. >From the 1003.1 standard, 2.8.2:
  19.  
  20.     Symbols called `feature test macros' are used to control the
  21.     visibility of symbols that might be included in a header.
  22.     Implementations, future versions of this standard, and other
  23.     standards may define additional feature test macros.
  24.  
  25. My interpretation of this text is that the 1003.1 committee wanted to
  26. provide a mechanism by which a number of standards and implementations
  27. could share the C namespace.  Of course, extended use of this mechanism
  28. is up to the other standards committees and implementors, and is
  29. outside the scope of 1003.1.  Perhaps this is an issue that Dot 0
  30. could help clear up.
  31.  
  32. >> The various 1003.* working groups are *not* developing separate 
  33. >components
  34. >> of an overall, integrated POSIX standard. Each POSIX standard stands 
  35. >alone....
  36.  
  37. Which makes it essential that each standard specify what it assumes
  38. is available from its host, and what it will add to the composite
  39. environment.  While each standard may stand alone, implementations
  40. certainly won't.
  41.  
  42. >As far as _POSIX_1_SOURCE goes, it's not clear to me why the existing 
  43. >_POSIX_SOURCE
  44. >can't be used (perhaps modified) for this purpose.
  45.  
  46. Because, unlike __STDC__, _POSIX_SOURCE is #defined or not #defined;
  47. its value is not significant.  The implication of the suggestion to use
  48. _POSIX_1_SOURCE for 1003.1a-conforming headers is that the 1003.1
  49. committee is reserving for its own use all feature test macro names
  50. that start with _POSIX_.  This means that the 1003.2 committee will be
  51. on shaky ground if they require that programmers #define
  52. _POSIX_2_SOURCE in order to make 1003.2 symbols visible.
  53.  
  54. The approach chosen by the ANSI C committee was a good one:  Use a single
  55. name for the feature test macro, and change the macro's VALUE when a
  56. new version of the standard supersedes an old one.
  57. -- 
  58.  
  59.     Chuck Karish        karish@mindcraft.com
  60.     Mindcraft, Inc.        (415) 323-9000        
  61.  
  62.  
  63. Volume-Number: Volume 20, Number 124
  64.  
  65.