This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: bz#15007: Fix mismatch of guards for qecvt
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 11 Apr 2013 14:16:23 -0700 (PDT)
- Subject: Re: bz#15007: Fix mismatch of guards for qecvt
- References: <515C5F33 dot 3070705 at suse dot com> <2678974 dot ZlRiEFqKvM at byrd> <20130408212034 dot 3B1332C085 at topped-with-meat dot com> <3912486 dot KZmDiiDHMs at byrd>
> 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
conditional.
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
names.)
Thanks,
Roland