[ dropping autoconf@ ] Hi Eric,
I hope you're enjoying your vacation and not looking so much at Autoconf. * Eric Blake wrote on Wed, Jul 07, 2010 at 07:17:30AM CEST: > ----- "Ralf Wildenhues" wrote: > > > On Sat, 3 Jul 2010 18:28:27 -0400 (EDT) Eric Blake wrote: > > > > Indeed, I spent a bit more time, and reproduced your follow-on > > > > issue. Here's the complete patch (the same as before in > > types.m4, > > > > plus a new patch in m4sh.m4), which should resolve the issue. > > > > Patch here. Eric, I'm not quite sure why you added the + to the > > _AS_TR_SH case. Can you explain, so I can add testsuite coverage? > > Thanks. > > The AS_TR_SH change was for the separate feature change in 2.66 of allowing > AS_ARG_WITH to allow + signs: the shell variable $as_with_c__ should > be allowed when you use ./configure --enable-c++ (typing from memory > here, so I may have some details off). To date, we use AS_TR_SH in > more places than AS_TR_CPP (namely, in the creation of shell variables > to track configure options), explaining the asymmetry between the > characters accepted by the two. Hmm, but at least the "AC_ARG_ENABLE and AC_ARG_WITH" test doesn't produce autoconf warnings for me when I remove the + from the patch, and the whole testsuite doesn't show any failures either. I'm afraid I need a bit more of a clue here: lib/autoconf/general.m4:_AC_ENABLE_IF already transliterates: m4_define([_AC_ENABLE_IF], [...@%:@ Check whether --$1-$2 was given. _AC_ENABLE_IF_ACTION([$1], m4_translit([$2], [-+.], [___]), [$3], [$4]) ]) and the latter macro is m4_define([_AC_ENABLE_IF_ACTION], [m4_append_uniq([_AC_USER_OPTS], [$1_$2], [ ])dnl AS_IF([test "${$1_$2+set}" = set], [$1val=$$1_$2; $3], [$4])dnl ]) where I can't see usage of any of the *_TR_* machinery nor the *LITERAL* macros. In light of this, should the `+' still be kept in _AS_TR_SH? > > More generaly, I'm not sure whether we should be testing all sorts of > > other characters, or what tests I should be adding to tests/m4sh.at: > > AS_TR_SH and AS_TR_CPP to expose these issues. Did your patch series > > intend to have any user-visible semantic impact at all (for existing > > prior defined semantics)? > > I did document in the NEWS that AS_LITERAL_IF has tighter semantics, > and treats some things as non-literals that used to be treated as > literals. The problem stems from how many places in the code > indirectly use portions of AS_LITERAL_IF, but allow different > sets of characters (most notable were AS_TR_SH and AS_TR_CPP). The > intent was not to break existing semantics, but to use less m4 > processing power (m4_translit is much faster than m4_regexp) for > setting up the heuristic for deciding whether an input string > is likely to be a shell literal. OK, so semantic changes other than that may be considered to be bugs. > > Fix regression of AC_CHECK_SIZEOF on pointer types. > > * lib/autoconf/types.m4 (AC_CHECK_SIZEOF): Translate `*' to `p' > > when checking literal-ness of the type, for pointer types. > > * lib/m4sugar/m4sh.m4 (_AS_TR_SH): Also translate `+' and `*' > > to `_'. > > (_AS_TR_CPP): Also translate `*' to `_'. > > Technically, these two changes in m4sh.m4 are along the lines of > 'allow * and + as literals rather than forcing non-literal > treatment'. Both the literal and shell versions of _AS_TR_CPP > were already set up to trigger the transliteration of * to _; > the problem was that the decision engine for whether to do the > work at m4 time or shell time was never picking m4 time before > this patch. OK, I'm changing the log to contain this instead: * lib/m4sugar/m4sh.m4 (_AS_TR_SH): Also consider `+' and `*' as literal. (_AS_TR_CPP): Also consider `*' as literal. pending above question about _AS_TR_SH. Thanks for the review. Cheers, Ralf