Re: _POSIX_C_SOURCE & _XOPEN_SOURCE standards conformance level macros

[John Hein]

Thomas Dickey dickey-at-his.com |bug_ncurses| wrote at 17:38 -0500 on Nov 20, 
2016:
 > On Sun, Nov 13, 2016 at 10:41:07AM -0700, John Hein wrote:
 > > 
 > > On FreeBSD, when using the ncurses port, pkg-config --cflags ncurses gives:
 > > 
 > > -I/usr/local/include -I/usr/local/include/ncurses -D_BSD_TYPES 
 > > -D__BSD_VISIBLE -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600
 > > 
 > > If you then use those flags to compile a program that happens to use
 > > ncurses, it will force your code to conform to that level of standards
 > > conformance.
 > > 
 > > Why would code that includes ncurses headers want or need to use
 > > _VISIBLE -D_POSIX_C_SOURCE=200112L and/or _XOPEN_SOURCE=600?
 > 
 > short: I generated the pc-files using the #define's which I used to
 > build ncurses.
 > 
 > long: It would be nice (perhaps) to postprocess that by pruning away
 > things that aren't necessary for compiling a client of the library.
 > 
 > That might be hard (since you get into combinations of definitions,
 > compilers that refuse to give error-exits on missing prototypes,
 > and weak-bindings that don't detect whether a function actually exists...)
 > 
 > Also, since I share those configure-checks across other programs, you
 > may find something not needed for ncurses in particular.

I think that if code including ncurses headers really requires that
those compatibility levels be set that way, the .pc should include
them in Cflags.  If not (which seems more likely) remove them from
Cflags.  The pkg-config Cflags is not supposed to be a reflection of
how the code was built, but rather what flags users of the library
need to use when compiling with the public headers of the library.

As you say, that may be complicated due to the variety of compiler/OS
versions out there.

But I think I'd start by removing those -D flags from Cflags and only
restore if needed.

As far as compilers that don't give errors on missing prototypes, I
don't that is ncurses' problem.  Most C compilers won't error out
unless you add something like -Werror anyway.  And most will provide a
warning by default these days (lack of a warning was more of a concern
20 years ago than today).

For actual undefined references and unresolved weak bindings, let
link/run-time catch any problems.  Certainly not the job of
compile-time flags to worry about those issues.

Shared configure-checks is definitely not sufficient justification for
unnecessary flags in .pc files.  Although I understand the case
regarding development convenience.

I think perhaps rather than building ncurses code with
-D_POSIX_C_SOURCE..., et. al., we should consider defining such
feature macros only in the .c modules that need them.  Maybe.  I think
that's the more typical usage of such macros.