gwyn@smoke.brl.mil (Doug Gwyn) (06/18/90)
From: Doug Gwyn <gwyn@smoke.brl.mil> [ Hm. Another one that got lost off the stack. I'm rearranging my mailboxes to avoid this sort of thing. -mod ] I've just been informed that the draft IEEE Std 1003.4 (possibly other POSIX standards-in-progress as well) specifies additional macros, including EVTCLASS_*, to be defined in <limits.h>. This deserves strong condemnation; there is NO EXCUSE for not using separate headers for the definitions for new facilities. In particular, stealing <limits.h> for this purpose forces portable applications to resort to the #define _POSIX_SOURCE /* or similar "feature test" macro */ #include <limits.h> kludge to obtain access to the new definitions, since the C standard quite properly prohibits the implementation from defining random stuff in strictly conforming programs. (Use of _POSIX_SOURCE provides an escape from strict conformance.) This kludgery would not be required for definitions obtained from a POSIX-specific header, e.g. <async.h> or even <posix4.h>. The reason for both X3.159 and 1003.1 sharing use of a few of the standard headers was simply that existing practice (and the base document for the C library) had already required symbols in them for both the general-C and UNIX-specific environments. However, that was a situation to be accommodated (and for which the special _POSIX_SOURCE had to be invented, although P1003 didn't do this the way that X3J11 recommended), not a practice to be actively encouraged. Apparently the people drafting the new standards don't understand why adding stuff to the standard headers is a bad idea. To give them something to think about, here is a practical problem: Development and installation of the additional facilities cannot be done, if the standard headers must be modified, without violating the integrity of a certified standard-conforming C implementation (and thereby losing certification). Volume-Number: Volume 20, Number 79