Roland McGrath - Re: bz#15007: Fix mismatch of guards for qecvt (original) (raw)

This is the mail archive of the libc-alpha@sourceware.orgmailing 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]

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

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