Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.std.c
Subject: Re: Re: __STDC__, _POSIX_SOURCE, etc.
Message-ID: <9500@smoke.BRL.MIL>
Date: 25 Jan 89 21:03:39 GMT
References: <9458@smoke.BRL.MIL> <12040009@hpfcdc.HP.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26

In article <12040009@hpfcdc.HP.COM> rml@hpfcdc.HP.COM (Bob Lenk) writes:
>The stated benefit is that the program does not have to be modified to
>#define _POSIX_SOURCE, since _POSIX_VERSION is defined by the
>implementation.  In practice this does not seem to be a real benefit,
>since it applies only to programs that already #include <unistd.h>
>before #including any other header (or at least any ANSI C related
>header); I doubt this covers any large number of existing programs. 
>Any other program requires a source change, which seems like no benefit
>over adding #define _POSIX_SOURCE.

I believe the reasoning was that technically <unistd.h> was going to
have to be included by almost any 1003.1-conformant application, and
that the automatic approach that takes care of the additional name-
space-in-standard-header issue would be less trouble than requiring
yet a second edit to the application as apparently required by the
_POSIX_SOURCE invention.  I will admit that finding "#define
_POSIX_SOURCE" as the first line of a source file might serve as a
useful indication that somebody has "POSIXized" the source.

If it is generally going to be the case that the POSIX compilation
environment predefines _POSIX_SOURCE then that is not a good argument.

I like the suggestion that 1003.1 publish a clarification of this
whole business.  If there are some non-required but generally agreed
techniques for the definition and use of these symbols, perhaps it
would be appropriate to try to steer vendors along the same path also.