Xref: utzoo comp.std.unix:761 comp.std.c:3339
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!longway!std-unix
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix,comp.std.c
Subject: POSIX and the standard headers
Keywords: POSIX standard C header macro specification
Message-ID: <764@longway.TIC.COM>
Date: 17 Jun 90 22:15:11 GMT
Sender: std-unix@longway.TIC.COM
Reply-To: std-unix@uunet.uu.net
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 37
Approved: jsq@longway.tic.com (Moderator, John S. Quarterman)

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