This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Patch] Fix ONE_DIRECTION undef warnings.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org
- Date: Wed, 30 Apr 2014 14:04:51 -0400
- Subject: Re: [Patch] Fix ONE_DIRECTION undef warnings.
- Authentication-results: sourceware.org; auth=none
- References: <c087928d-c0a6-4121-8236-84a1a9e59870 at BAMAIL02 dot ba dot imgtec dot org> <20140428174126 dot 18CE02C3A00 at topped-with-meat dot com> <535FFE81 dot 4060104 at redhat dot com> <1398802315 dot 14541 dot 48 dot camel at ubuntu-sellcey> <5360162B dot 90303 at redhat dot com> <1398877703 dot 5201 dot 10 dot camel at ubuntu-sellcey> <5361361F dot 3090304 at redhat dot com> <1398880631 dot 5201 dot 17 dot camel at ubuntu-sellcey>
On 04/30/2014 01:57 PM, Steve Ellcey wrote:
> On Wed, 2014-04-30 at 13:42 -0400, Carlos O'Donell wrote:
>
>> Steve, Please don't take my word for it, and if you think this entire
>> exercise is stupid please say so. However, I agree with Roland that there
>> is considerable value in fixing up these "macro as interface" issues to
>> the point where an undefined macro is an error. Particularly when it
>> comes to ABI issues that might go unnoticed like the Power 2.18 ABI
>> issue around librt which was fixed by accident.
>
> Frustrating and annoying but not stupid. If we could get there at zero
> cost I would have no issues with the direction we are going. My main
> problem is with the amount of change needed to get there and about
> whether anyone was actually working on the changes.
I signed up for it and right now I'm tackling FEATURE_INDEX_1 in x86,
which Roland had some comments about.
I think everyone is pitching in to help, and I'm trying to review the
changes with an eye towards fixing them correctly.
I admit the ugly warnings are there as incentive to fix the issue :-)
>> I agree that fixing this requires mechanical addition of defining
>> ONE_DIRECTION in each converter as part of the API contract with
>> using the skeleton.c file. This is core cleanup work that will bear
>> fruit!
>
> Yes, I think (hope) ONE_DIRECTION is the worst case scenario that we
> have.
See my other email where I acknowledge your general idea of a single
default header definition being potentially useful here now and in
the future.
Cheers,
Carlos.