This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]