Re: avoiding undesired macro expansion after AS_TR_CPP

[Eric Blake]

On 06/03/2010 05:59 PM, Bruno Haible wrote:
> Hi Eric,
> 
>> On the other hand, why not use:
>>
>> AM_CONDITIONAL(AS_TR_CPP([[LIBUNISTRING_$1]]), [true])
> 
> Yes, I'm using this trick now.
> 
>>>> AM_CONDITIONAL([LIBUNISTRING_]AS_TR_CPP([[$1]]), [true])
>> AM_CONDITIONAL(AS_TR_CPP([[LIBUNISTRING_$1]]), [true])
> 
> You seem to insist that the problem is with the _argument_ of AS_TR_CPP.
> If I write
>          AS_TR_CPP([[libunistring_foo_bar]]
> this might well help to avoid unwanted expansion of the argument (the
> lowercase string). But my problem is with the _result_ of AS_TR_CPP, the
> uppercase string.

I've already determined that AS_TR_CPP underquotes its argument during
processing, so no amount of quoting from the user can work around it.

The question, though, is whether AS_TR_CPP([abc]) should output a quoted
string (which is a change in behavior, but arguably more like
m4_toupper), or a raw string (no worse than what we have today, but
where AS_TR_CPP([[abc]]) would work where today it doesn't).


> 
> As an autoconf user, I would find it very strange and surprising to have
> to add quoting inside the arguments of a macro call when I want to avoid
> expansion of the result.

The rule of thumb is to double-quote anything that you don't want to be
further expanded.  Hence, it might make sense to say that
AS_TR_CPP([abc]) will be expanded and AS_TR_CPP([[abc]]) will not.  On
the other hand, it also makes sense that for strict textual conversions,
the macro should already output quoted text.  It's a bug fix either way,
so which way do you prefer?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature