🚀 go-pugleaf

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.