This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] Define PTR_MANGLE and PTR_DEMANGLE unconditionally.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, libc-alpha at sourceware dot org
- Date: Thu, 07 Nov 2013 12:26:20 -0500
- Subject: Re: [PATCH 1/2] Define PTR_MANGLE and PTR_DEMANGLE unconditionally.
- Authentication-results: sourceware.org; auth=none
- References: <20131031194113 dot GA30302 at domone dot podge> <5272B2DA dot 8090807 at redhat dot com> <20131105093831 dot GA21063 at domone dot podge> <8738na1zx6 dot fsf at igel dot home> <20131106122419 dot GA9792 at domone dot podge> <527BBF14 dot 8050408 at redhat dot com> <20131107165241 dot GA18518 at domone>
On 11/07/2013 11:52 AM, OndÅej BÃlka wrote:
> On Thu, Nov 07, 2013 at 11:25:56AM -0500, Carlos O'Donell wrote:
>> On 11/06/2013 07:24 AM, OndÅej BÃlka wrote:
>>> On Tue, Nov 05, 2013 at 07:11:49PM +0100, Andreas Schwab wrote:
>>>> OndÅej BÃlka <neleai@seznam.cz> writes:
>>>>
>>>>> Moving these would involve creating a new header. A posibility would be
>>>>> a defaults header where we would move various compatibility definitions.
>>>>
>>>> That file could be sysdeps/generic/sysdep.h.
>>>>
>>> We should first make clear ordering issues. As for PTR_MANGLE a generic
>>> comes before PTR_MANGLE is defined so we need extra undef before each
>>> definition.
>>>
>>> With file included as last these will not be needed.
>>>
>>> Also when we expand this I am bit afraid of inconsistencies when half
>>> can be defined before this file and other half after it is included.
>>
>> What inconsistencies would there be?
>>
>> It is true that we might need #undef FOO before you define your own,
>> but that's normal for all macros that have early defined defaults and
>> it's not bad as fars I care.
>>
> For early defaults you cannot supply alternative implementation
> -DALTERNATIVE= or you need another macro that signals default.
I agree that using -DALTERNATIVE= can't be used in this case.
> With late default this is not problem.
I agree.
> This is more matter of consistently defining defaults early/late and
> accepting problems.
However, you could start by fixing things even if -DALTERNATIVE=
was not supported. After the fix we can reorganize things so the
defaults are defined late, and then we're done?
Either way I see the current cleanup as orthogonal, and yes it means
-DALTERNATIVE= doesn't work for now.
Cheers,
Carlos.