Re: AC_CHECK_SIZEOF([int *]) is error in autoconf-2.66

[Ralf Wildenhues]

[ 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],
address@hidden:@ 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