home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.27 / text0097.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  4.9 KB  |  94 lines
  1. Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
  2.  
  3. jwag@moose.asd.sgi.com (Chris Wagner) writes:
  4.  
  5. >I am trying to figure out the feature test macro for POSIX1003.4 and 4a.
  6. >Although draft 12 gives lots of compile-time option constants, it seems
  7. >to imply that the only feature test macro is _POSIX_C_SOURCE.
  8. >Draft12 seems to imply that as of a certain date (the date of approval
  9. >I assume) all the symbols defined in POSIX1003.4 will suddenly be
  10. >added to header files such as stdio.h, etc. A user can optionally
  11. >set _POSIX_C_SOURCE to an earlier date to preclude certain symbols.
  12. >Is this right?? It seems kind of silly to base visibility on date.
  13. >I would expect that most  developers will still want to be able
  14. >to demand a pure 1003.1 symbol environment.
  15. >Is this _POSIX_C_SOURCE just a 1003.4 hack? or has it been
  16. >formally adopted at the way the future POSIX stds will
  17. >be added to existing headers.
  18.  
  19. A short tutorial on POSIX feature test macros ...
  20.  
  21. OK, here's the the way it works.  An ANSI C compiler is not allowed to
  22. make symbols visible to an application beyond what's defined in ANSI
  23. C, unless the application does something explicit to make those
  24. symbols available.  The application does this by defining one or more
  25. feature test macros before including any headers.  Basically, if the
  26. application defines a feature test macro, it is saying that it "knows"
  27. about, and is willing to deal with, the additions to the name space
  28. that are associated with that feature test macro.
  29.  
  30. _POSIX_C_SOURCE is the new POSIX method for controling visibility of
  31. POSIX symbols.  The application sets _POSIX_C_SOURCE to a date value,
  32. and that PERMITS the implementation to make visible any symbols
  33. associated with parts of POSIX that were approved on or before that
  34. date.  (Using a date as the value is arbitrary.  A simple integer that
  35. was incremented with each new revision could have been used, but we
  36. felt that a date would be more meaningful to humans.)  The
  37. implementation then informs the application which options it actually
  38. supports through version macros (e.g. _POSIX_VERSION and
  39. _POSIX2_C_VERSION), or specific "feature present" macros (e.g.
  40. _POSIX_SYNCHRONIZED_IO).
  41.  
  42. So, if an application only wants to see only POSIX.1 ("POSIX Classic"),
  43. then it will define _POSIX_SOURCE.  Only symbols defined in IEEE
  44. Std 1003.1-1990 (or -1988) will appear, even if the implementation
  45. supports POSIX.2, POSIX.4, and ten other options that haven't been
  46. created, yet.  An application that needs POSIX.1 and POSIX.2 Annex B
  47. will define _POSIX_C_SOURCE to 199208L [exact value not yet
  48. determined], and POSIX.4 symbols will not appear.  An application that
  49. wants only POSIX.4 will define _POSIX_C_SOURCE to 199209L [again,
  50. exact value not yet determined], and the implementation is then
  51. permitted to make visible symbols from POSIX.1, POSIX.2, and POSIX.4.
  52.  
  53. A couple of things to note:
  54. (1) Just because the application sets _POSIX_C_SOURCE to a value, does
  55.     not mean that the imlementation supports all of the requested
  56.     options.  If the application sets _POSIX_C_SOURCE to 199209L
  57.     [using the above example] but the implementation doesn't support
  58.     POSIX.4, then clearly POSIX.4 symbols might or might not appear.
  59. (2) There is no way for an application to say "I want POSIX.4 symbols
  60.     but NOT POSIX.1 or POSIX.2 symbols.  It doesn't need to use the
  61.     unwanted options, but it must respect the reserved namespace of all
  62.     options defined before
  63. (3) It is our hope that the IEEE will publish a table saying "here are
  64.     the symbols defined if <header.h> is included and _POSIX_C_SOURCE
  65.     is set to yyyymmL" whenever a new revision is approved.
  66. (4) If this was all consistent, defining _POSIX_C_SOURCE as 199009L
  67.     would be equivalent to defining _POSIX_SOURCE.  Unfortunately,
  68.     that isn't required by the current version of POSIX.1.
  69.  
  70. >It seems to me that each standard should add feature test macros that
  71. >can be defined at compile time...(e.g. _POSIX_4SOURCE, etc.)
  72.  
  73. The feature test macros are defined at compile time, it's just that
  74. there is only one feature test macro instead of many.
  75.  
  76. Something that many people don't understand is that the different
  77. POSIX.* docuements are not different standards.  POSIX.2 Annex B,
  78. POSIX.4, POSIX.4a, POSIX.1a, plus several others, are revisions of
  79. POSIX.1 describing optional features.  Ultimately, they are all
  80. considered part of one ISO standard, 9945-1.  (Somebody will probably
  81. correct me on this, but 9945-2 is shell and utilities [most of POSIX.2],
  82. and 9945-3 is system administration.) So it actually makes more sense
  83. for all of the C bindings to use the same feature test macro than to
  84. give each option of the standard its own feature test macro. 
  85.  
  86. David A. Willcox        "Just say 'NO' to universal drug testing"
  87. Motorola MCG - Urbana        UUCP: ...!uiucuxc!udc!willcox
  88. 1101 E. University Ave.        INET: willcox@urbana.mcd.mot.com
  89. Urbana, IL 61801        FONE: 217-384-8534
  90.  
  91.  
  92. Volume-Number: Volume 27, Number 96
  93.  
  94.