home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0102.txt < prev   
Encoding:
Text File  |  1992-05-20  |  3.0 KB  |  54 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <v139nINNr4n@ftp.UU.NET> willcox@urbana.mcd.mot.com (David A Willcox) writes:
  4. >OK, here's the the way it works.  An ANSI C compiler is not allowed to
  5. >make symbols visible to an application beyond what's defined in ANSI
  6. >C, unless the application does something explicit to make those
  7. >symbols available.  The application does this by defining one or more
  8. >feature test macros before including any headers.
  9.  
  10. More accurately:  In order to conform to the C standard, a C implementation
  11. must, among other requirements, accept any strictly conforming C program.
  12. A strictly conforming C program must, among other requirements, not use
  13. certain classes of identifiers in contexts where they have been reserved
  14. for use by C implementations.  And a conforming C implementation must not
  15. define any identifiers in the standard headers other than those specified
  16. in the standard plus those reserved for implementations.  (Reserved
  17. identifiers mostly begin with underscore; see the C standard for details.)
  18.  
  19. There are no requirements on any headers other than those specified in the
  20. standard; thus additional facilities can AND SHOULD be defined by separate
  21. headers, not through modifications to the standard headers.  This is
  22. especially important when the standard C implementation is provided by
  23. one source of supply but the additional functionality is provided by a
  24. different source of supply, as frequently ocurs in this industry.
  25.  
  26. The only reason there was any need for "feature flags" in the first place
  27. was the historical accident that some of the standard headers (notably
  28. <stdio.h>) included interface definitions for UNIX-specific facilities AND
  29. general portably-available facilities.  The C standard does not single out
  30. the UNIX environment for an exception, but rather prohibits pollution of
  31. the identifier name spaces by ANY conforming implementation.  Thus, for
  32. <stdio.h> and a few other standard headers, a conforming C implementation
  33. can make additional non-reserved symbols (such as "popen") visible ONLY to
  34. programs that are NOT strictly conforming.  The method chosen by 1003.1 for
  35. this was for the program to somehow #define _POSIX_SOURCE before including
  36. the relevant standard header.  This allows the implementation to key on
  37. that symbol to "turn on" additional symbols in the standard header, without
  38. those symbols being visible in the absence of such a feature flag.
  39.  
  40. As the last acting liaison between X3J11 and P1003, I was heavily involved
  41. in getting this issue resolved.  1003.1 did not quite follow X3J11's
  42. recommendations, apparently adopting a different view of feature flags,
  43. and from what David has said I gather that the repeated message from X3J11
  44. to 1003 to not further pollute the standard headers has gotten lost.
  45.  
  46. For NEW facilities (i.e. not those inherited from historic implementations
  47. of UNIX), use new, distinct headers for defining new interfaces; don't add
  48. new symbols (whether or not under control of feature flags) to standard C
  49. headers.  Please!
  50.  
  51.  
  52. Volume-Number: Volume 27, Number 101
  53.  
  54.