__STDC__, _POSIX_SOURCE, etc.

Doug Gwyn gwyn at smoke.BRL.MIL
Thu Jan 26 07:03:39 AEST 1989


In article <12040009 at hpfcdc.HP.COM> rml at 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.



More information about the Comp.std.c mailing list