home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0080.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  1.9 KB
  1. From:  Doug Gwyn <gwyn@smoke.brl.mil>
  2.  
  3. [ Hm.  Another one that got lost off the stack.  I'm rearranging
  4. my mailboxes to avoid this sort of thing.  -mod ]
  5.  
  6. I've just been informed that the draft IEEE Std 1003.4 (possibly
  7. other POSIX standards-in-progress as well) specifies additional
  8. macros, including EVTCLASS_*, to be defined in <limits.h>.  This
  9. deserves strong condemnation; there is NO EXCUSE for not using
  10. separate headers for the definitions for new facilities.  In
  11. particular, stealing <limits.h> for this purpose forces portable
  12. applications to resort to the
  13.     #define _POSIX_SOURCE    /* or similar "feature test" macro */
  14.     #include <limits.h>
  15. kludge to obtain access to the new definitions, since the C
  16. standard quite properly prohibits the implementation from
  17. defining random stuff in strictly conforming programs.  (Use of
  18. _POSIX_SOURCE provides an escape from strict conformance.)  This
  19. kludgery would not be required for definitions obtained from a
  20. POSIX-specific header, e.g. <async.h> or even <posix4.h>.
  21.  
  22. The reason for both X3.159 and 1003.1 sharing use of a few of the
  23. standard headers was simply that existing practice (and the base
  24. document for the C library) had already required symbols in them
  25. for both the general-C and UNIX-specific environments.  However,
  26. that was a situation to be accommodated (and for which the special
  27. _POSIX_SOURCE had to be invented, although P1003 didn't do this
  28. the way that X3J11 recommended), not a practice to be actively
  29. encouraged.  Apparently the people drafting the new standards
  30. don't understand why adding stuff to the standard headers is a
  31. bad idea.  To give them something to think about, here is a
  32. practical problem:  Development and installation of the additional
  33. facilities cannot be done, if the standard headers must be modified,
  34. without violating the integrity of a certified standard-conforming
  35. C implementation (and thereby losing certification).
  36.  
  37. Volume-Number: Volume 20, Number 79
  38.  
  39.