Re: __need macros for communication with compiler-provided headers

[Carlos O'Donell <carlos at redhat dot com>]

On 03/22/2017 11:21 AM, Zack Weinberg wrote:
> As you may recall I have been working on abolishing __need macros in
> favor of micro-headers that define one type (bits/types/*.h) My branch
> for this (zack/headers-cleanups) has reached the point where most of
> the remaining __need macros are used to communicate with
> compiler-provided headers: __need_NULL, __need_ptrdiff_t,
> __need_size_t, __need_wchar_t all request single definitions from
> stddef.h, __need___va_list requests a single (nonstandard) definition
> from stdarg.h, and __need_int_reg_t requests a single definition from
> the Tile-specific arch/abi.h (I don't _know_ that this is provided by
> the compiler, but it's not in our source tree).
> 
> Obviously we cannot change how this works completely unilaterally.  We
> could write wrapper bits/types/ headers that consolidate the _use_ of
> __need macros, but I'm not sure it's worth it; the real value to these
> patches is in cleaning up the code that _implements_ the __need
> macros.  GCC and compatible compilers are pretty much stuck supporting
> the __need mechanism forever, along with similar mechanisms for other
> C libraries (have you ever looked at gcc's stddef.h?)
> 
> ... Basically what I'm asking the room is: do we think there _is_ a
> design that would be abstractly better for these types, and is there
> any way to get there from here, assuming coordination between us and
> several compiler teams?
> 
> For the curious, here are usage counts:
> 
>       2 __need_ptrdiff_t
>       3 __need_int_reg_t
>       5 __need___va_list
>      11 __need_wchar_t
>      30 __need_NULL
>      55 __need_size_t

Something simpler to use and understand than micorheaders? Duplication of
definitions?

The complexity of __need_t is in the desire to have a single header that
does everything the standard requires _and_ have a knob to use to get at
just one definition. This complicates things immensely for the implementor
and the micorheader solution is an elegant replacement.

I'd expect the following to be a plausible way forward:

(1) Convince compiler teams that the microheaders that define one type
    are the way to go.
(2) Work across the compilers to implement the micro-headers but leave
    the required __need_* support in place that just includes a microheader.
(3) In glibc migrate everything to use microheaders, wrapping the compiler
    __need_* in a microheader.
(4) Make note in the glibc wrapper microheader the point at which the
    wrapper can be deleted when a new enough compiler has the micorheader.
(5) Eventually delete the wrappers when glibc moves the compiler used for
    glibc builds and the compiler supported for application builds moves
    up to a version that has microheaders.

-- 
Cheers,
Carlos.