This is the mail archive of the
mailing list for the glibc project.
Re: [Patch] Fix ONE_DIRECTION undef warnings.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Steve Ellcey <sellcey at mips dot com>, libc-alpha at sourceware dot org
- Date: Wed, 30 Apr 2014 14:20:21 -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> <20140430175647 dot DC6392C39DE at topped-with-meat dot com> <53613A9F dot 1060701 at redhat dot com> <20140430181003 dot 8C5582C39D5 at topped-with-meat dot com>
On 04/30/2014 02:10 PM, Roland McGrath wrote:
>> As Steve suggested in another email it might make sense to have a single
>> header define "macro API" defaults, that make sense for 99% of the
>> configurations. It would make it easy to adjust them en-masse instead of
>> rafactoring the changes across the 54 source files that use it.
> The obvious way to do this makes all those source files places where typos
> could go unnoticed. We should think hard about ways to reduce that danger.
> IMHO this is a stronger motivator than avoiding duplicate changes that can
> be easily mechanized. The former leads to silent bugs gone unnoticed,
> which is a risk of real user harm that might not be noticed until much
> later. The latter leads to build errors/warnings that alert one early to
> the need to do the annoying mechanically-duplicative change, which is a
> certainty of immediate slight maintainer annoyance that happens immediately
> to the maintainer who instigated the change.
That sounds like you're against the default header design. Could you clarify
your position on that?
My thoughts on the matter are:
(a) The default header defines defaults e.g.
#define FOO 0
(b) The uses include it early.
(c) Uses that need to override defaults do so like this.
#define FOO 1
(d) All uses of FOO remain safe.
(1) Include is late.
#define FOO 1
Multiple definition error. Developer has to fix it immediately.
(2) Wrong default.
Can't be fixed.
If you specify the wrong value that's logical error we can't correct.
(3) Complicates include order.
In that it must be:
Or it doesn't work and we have the similar includes problem as defined here:
If you aren't against default headers, is your statement to serve as a reminder
that the build should fail early and immediately and such implementations should
be chosen over those that done? I agree.