This is the mail archive of the 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: bz#15007: Fix mismatch of guards for qecvt

> On Monday, April 08, 2013 14:20:34 Roland McGrath wrote:
> > > Is this what you had in mind for stdlib.h?
> > 
> > No, it's pretty much the opposite.
> > Just "#ifdef __USE_MISC" at top-level ought to suffice.
> I'm not following you, could somebody tell me where my reasoning is 
> wrong?
> So, I'm not following why these two should be equivalent:
> #if (defined __USE_XOPEN_EXTENDED && !defined __USE_XOPEN2K8) \
>     || defined __USE_SVID
> and
> #ifdef __USE_MISC

They should not be.  I guess I was not clear.  The status quo is that
"#ifdef __USE_MISC" appears inside that other condition.  Since __USE_SVID
implies __USE_MISC, that is redundant.  Furthermore, in the case where
neither __USE_XOPEN_EXTENDED nor __USE_SVID is defined but __USE_BSD (and
thus __USE_MISC) is defined, qecvt et al should be declared.  So what I
said to do was move the "#ifdef __USE_MISC" section outside the other

The original intent of all the __USE_* macros was that they would always be
used singly.  That's why we have __USE_MISC at all instead of just using
"#if defined __USE_BSD || defined __USE_SVID" everywhere.  That is, all the
headers would only ever have simple "#ifdef __USE_FOO" conditionals (never
nested), specifically so that features.h is the one and only place where
all the complex interrelationships have to be understood.  The hope was to
avoid ever dealing with exactly the kind of confusion we are having now.
But this has now become quite muddled.

It would be a worthy project for someone to go in and clean this all up
again.  All the interactions probably necessitate some new __USE_* macros
at finer grain.  But the situation can probably be simplified nowadays
because I think we could drop _BSD_SOURCE and _SVID_SOURCE entirely from
the API (they've gone the way of K&R C).  For all modern source code, it
seems reasonable enough to support just the various standard-specified
feature macros plus _GNU_SOURCE.  (By implication we'd drop __FAVOR_BSD and
the things it enables.  For struct tcphdr/udphdr we could perhaps use some
anonymous unions to support both the original (BSD) and the Linuxoid field


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