fnmatch.h: use standard internal defines

  Use features.h for the start/end brackets of C code, and switch to using
__USE_GNU/__USE_XOPEN rather than parsing the symbols directly.

We also drop support for exporting the GNU-extensions when _POSIX_C_SOURCE
is defined to 1 as these aren't in POSIX.

2016-11-27  Mike Frysinger  <vapier@gentoo.org>

	* posix/fnmatch.h: Include features.h.  Replace extern "C" with
	__BEGIN_DECLS and __END_DECLS.  Drop _POSIX_C_SOURCE checking.
	Change _GNU_SOURCE to __USE_GNU.  Change _XOPEN_SOURCE to
	__USE_XOPEN.
---
 posix/fnmatch.h | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)
  

Mike Frysinger wrote:
> Use features.h for the start/end brackets of C code, and switch to using
> __USE_GNU/__USE_XOPEN rather than parsing the symbols directly.

Doesn't this match fnmatch.h unnecessarily harder to share with Gnulib?
  

On 27 Nov 2016 08:31, Paul Eggert wrote:
> Mike Frysinger wrote:
> > Use features.h for the start/end brackets of C code, and switch to using
> > __USE_GNU/__USE_XOPEN rather than parsing the symbols directly.
> 
> Doesn't this match fnmatch.h unnecessarily harder to share with Gnulib?

gnulib already has this problem (and deals with it) with glob.h and regex.h.
maybe it's time to create a new internal gnulib module to unify that ?
-mike
  

On Sun, Nov 27, 2016 at 2:04 AM, Mike Frysinger <vapier@gentoo.org> wrote:
...
> @@ -47,7 +47,7 @@ extern "C" {
>     `fnmatch'.  Since this is not the case here it will never be
>     returned but the conformance test suites still require the symbol
>     to be defined.  */
> -#ifdef _XOPEN_SOURCE
> +#ifdef __USE_XOPEN
>  # define FNM_NOSYS     (-1)
>  #endif

As long as we're touching this file,
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fnmatch.h.html
says FNM_NOSYS was deprecated-XSI in Issue 6 and dropped in Issue 7,
which I *think* means this conditional should be

    #if defined __USE_XOPEN && !defined __USE_XOPEN2K8

(I'm not having any luck finding an online copy of Issue 4 - the Open
Group seems to believe nobody needs to look at it anymore.)

zw
  

Mike Frysinger wrote:
> maybe it's time to create a new internal gnulib module to unify that ?

That would be one way; another is to treat fnmatch.h like regex.h etc. i.e. to 
duplicate the "#define _USE_GNU" code.
  

On Sun, 27 Nov 2016, Zack Weinberg wrote:

> (I'm not having any luck finding an online copy of Issue 4 - the Open
> Group seems to believe nobody needs to look at it anymore.)

The link I gave in 
<https://sourceware.org/ml/libc-alpha/2015-07/msg00902.html> still works 
for me.