Re: __need macros for communication with compiler-provided headers

[Zack Weinberg <zackw at panix dot com>]

On Wed, Mar 22, 2017 at 2:08 PM, Chris Metcalf <cmetcalf@mellanox.com> wrote:
> On 3/22/2017 11:21 AM, Zack Weinberg wrote:
>> __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).
>
> It's provided in the Linux tree, as arch/tile/include/uapi/arch/abi.h .
> In retrospect I'm not sure this was the cleanest possible approach,
> but it's the one we ended up using.

Oh, it's a kernel header?  Those are much easier to change than
compiler-provided headers ;-)

The issue from my perspective is that the __need idiom makes the
header that *implements* it much harder to maintain, because it
conflicts with multiple-inclusion guards -- and any nontrivial C
header probably needs a multiple-inclusion guard.  In some cases we
had outright bugs because of this.

What I've been doing with our own headers, therefore, is replacing
__need macros with "microheaders" each of which defines just one type.
For example, through glibc 2.24 sched.h had

#define __need_time_t
#define __need_timespec
#include <time.h>

and now instead it has

#include <bits/types/time_t.h>
#include <bits/types/struct_timespec.h>

So my suggestion would be that you provide an uapi/arch/int_reg_t.h
(or something like that; it doesn't matter what the name is) that
_only_ defines int_reg_t (and names in the implementation namespace)
and then the glibc headers that need int_reg_t can include that.
You'll find, when you make this change, that arch/abi.h is suddenly
quite a bit tidier.

The catch though is that we do need a transition plan.  I suspect it's
not a big deal if old libc headers + new kernel headers start getting
_all_ of arch/abi.h from the small number of headers that use the
__need macro, so maybe it can be as simple as "as of version X.Y of
glibc we require version A.B.C or later kernel headers for Tile."

zw