__need macros for communication with compiler-provided headers

[Zack Weinberg <zackw at panix dot com>]

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

zw