This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] ARM gas: handle {...} operands in macros


>>> On 03.06.13 at 18:11, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 03/06/13 17:08, Jan Beulich wrote:
>>>>> On 03.06.13 at 18:01, Richard Earnshaw <rearnsha@arm.com> wrote:
>>> On 03/06/13 16:58, Jan Beulich wrote:
>>>>>>> On 03.06.13 at 17:49, Richard Earnshaw <rearnsha@arm.com> wrote:
>>>>> On 28/05/13 20:18, Roland McGrath wrote:
>>>>>> Here's another case where the presumptions about whitespace stripping don't
>>>>>> mesh with macros quite right.  There may be more cases affected; I didn't
>>>>>> try to add test cases for all of them.
>>>>>>
>>>>>> OK for trunk and 2.23?
>>>>>
>>>>> This seems all wrong to me.  If you're having to pretend that all these
>>>>> special characters are symbol characters, then something else must be
>>>>> fundamentally wrong.  That makes this patch a crutch for something else
>>>>> that's broken.
>>>>>
>>>>> I think you need to dig further into why macros aren't working properly.
>>>>>     Is it the implementation of macros, the documentation, or your
>>>>> expectations that are wrong?
>>>>
>>>> Others (including me) have done this before - it's an effect of
>>>> how the scrubber works, eating whitespace that it thinks isn't
>>>> necessary. It's been years back that I looked into that, but iirc
>>>> in the end I was told to better leave the scrubber untouched to
>>>> not risk breakage elsewhere. So one or the other workaround
>>>> needs to be found anyway...
>>>>
>>> This is more than just the white-space scrubbing.  It's changing the
>>> definition of what characters are legal in symbols.  I'm concerned that
>>> that may have other potential implications for parsing as well.
>>
>> Oh, yes, I understand that this has the potential for breakage
>> elsewhere. But that was true for the earlier addition of [ and ] too.
>> Perhaps there are other solutions, but likely much more intrusive
>> to the code.
> 
> I guess the real question is, when is this going to stop?  All these 
> additions are wrong and it's looking to me as though this is going to be 
> a drip drip drip of 'Oh, here's another one'.  Fundamentally, these 
> changes are all wrong; these aren't symbol characters and trying to 
> pretend that they are is papering over the real problem and potentially 
> introducing new bugs.

I agree with all of this, yet the pragmatic reply here is "Whenever
someone has enough spare time to investigate and implement a
proper solution." Till then, keeping things working for people is
likely going to have higher importance than the reservations you
have (after all, I don't see real badness from allowing "[]{}" and
perhaps a few more in symbol names at the scrubber layer. In
fact, I would generally think that at that layer almost all non-blank,
non-operator, non-comment characters could be permitted in
symbol names.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]