This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [hurd,commited] hurd: do not check Mach and Hurd headers
On Sun, 4 Mar 2018, Samuel Thibault wrote:
> Joseph Myers, on dim. 04 mars 2018 01:33:18 +0000, wrote:
> > On Sun, 4 Mar 2018, Samuel Thibault wrote:
> > > > But in any case where, after analysis, such a #error is found to
> > > > make sense (and a comment goes on the #error explaining why it
> > > > makes sense), that specific header might have testing disabled in
> > > > check-installed-headers.sh *only* when _GNU_SOURCE is not passed - not
> > > > for other feature test macros, not using wildcards like hurd/*.h.
> > >
> > > I have sent a patch adding support for this, and whitelisting mach
> > > headers, could you have a look?
> >
> > It's not yet clear any such special cases in the script are needed.
>
> See the patch: mach/mach/mig_support.h explains why it needs
> _GNU_SOURCE.
Well, I disagree with the explanation there. The use of __stpncpy is in
an _LIBC-conditional block, and _LIBC can reasonably be taken to imply
_GNU_SOURCE, so if you remove the #error I see no reason for this header
to break without _GNU_SOURCE. It just requires a few Mach-specific types,
and all the headers declaring such types should do so unconditionally.
(Such _LIBC-conditional code should where possible move out of installed
headers and into non-installed headers used only for building glibc, but
that's a separate longstanding issue. _LIBC conditionals are more
appropriate for e.g. code shared with gnulib.)
> > But
> > if they are, they would only be for specific headers that use #error
> > without __USE_GNU, not any wildcard such as hurd/*.h,
>
> Sure, I _*NEVER*_ meant to do anything like that, as my patch shows.
My reading of <https://sourceware.org/ml/libc-alpha/2018-03/msg00074.html>
is that it still has:
+ # Hurd headers are not standard anyway
+ (hurd.h | hurd/*.h | faultexc_server.h)
+ continue;;
and as noted, I don't think hurd/*.h should be special-cased like that (or
that "not standard" is a sufficient explanation for a comment here).
--
Joseph S. Myers
joseph@codesourcery.com