home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0001.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.4 KB  |  75 lines
  1. Submitted-by: willcox@urbana.mcd.mot.com (David A Willcox)
  2.  
  3. gwyn@smoke.brl.mil (Doug Gwyn) writes:
  4.  
  5. >There are no requirements on any headers other than those specified in the
  6. >standard; thus additional facilities can AND SHOULD be defined by separate
  7. >headers, not through modifications to the standard headers.  This is
  8. >especially important when the standard C implementation is provided by
  9. >one source of supply but the additional functionality is provided by a
  10. >different source of supply, as frequently ocurs in this industry.
  11.  
  12. Doug makes the good point that I glossed over in my original posting,
  13. that ANSI C only speaks to its own headers.  POSIX's feature test macros
  14. were needed to allow an implementation to make POSIX symbols visible
  15. when a POSIX application includes ANSI C headers.  (<stdio.h>, <limits.h>,
  16. <errno.h>, <signal.h>, <setjmp.h> are the ones I can think of offhand.
  17. There may be others.)
  18.  
  19. ANSI C didn't require feature test macros for non-ANSI headers like
  20. <unistd.h> or <pwd.h>.  Under the ANSI C rules, an implementation can
  21. do almost anything it wants when an application includes a non-ANSI
  22. header.  However, we felt that it made sense to extend the feature test
  23. macro concept to all POSIX headers for several reasons:
  24.  
  25. (1) It is a good way to handle applications that want different
  26.     versions of the standard.  (See the posting that started this
  27.     thread.)
  28. (2) There were, and still are, UNIX(tm)oid systems in the world
  29.     with subtle and unsubtle differences from POSIX.  The feature
  30.     test macros allow them to support POSIX applications and
  31.     applications written specifically for those implementations.
  32. (3) It is more consistent to treat all headers mentioned in POSIX
  33.     the same.
  34.  
  35. (I'm not sure that we had all of these reasons in mind when we
  36. originally did it, but they are still good reasons. ;-) )
  37.  
  38. >As the last acting liaison between X3J11 and P1003, I was heavily involved
  39. >in getting this issue resolved.  1003.1 did not quite follow X3J11's
  40. >recommendations, apparently adopting a different view of feature flags,
  41. >and from what David has said I gather that the repeated message from X3J11
  42. >to 1003 to not further pollute the standard headers has gotten lost.
  43.  
  44. I don't think that the message has been entirely lost.  See below.
  45.  
  46. (Speaking only for myself: I don't think that it "pollutes" a header if
  47. things that are added to a header that are releated to the original
  48. use of the header, and the additions are only visible to POSIX
  49. applications.)
  50.  
  51. >For NEW facilities (i.e. not those inherited from historic implementations
  52. >of UNIX), use new, distinct headers for defining new interfaces; don't add
  53. >new symbols (whether or not under control of feature flags) to standard C
  54. >headers.  Please!
  55.  
  56. I think that that's pretty much what we've been doing.  For the most
  57. part, the new C interfaces have beed added in new headers, not in
  58. existing ones.  1003.2, 1003.4, and 1003.4a are full of new headers. 
  59.  
  60. It's true, there are some cases where things have been added to ANSI C
  61. headers:
  62.  
  63.   - New error numbers added to <errno.h>.
  64.   - New limits added to <limits.h>.
  65.   - New signal-related stuff added to <signal.h>
  66.  
  67. but with the exception of the <limits.h> stuff, the additions are
  68. reasonably related to what is already in the header, and it seems
  69. logical to add the new interfaces there.  I might be inclined to agree
  70. with Doug on the <limits.h> additions. 
  71.  
  72.  
  73. Volume-Number: Volume 28, Number 2
  74.  
  75.