Re: gettext.m4 bug

[Bruno Haible]

Eric Blake wrote:
> > Thanks for reporting this. Your patch works, but I'm applying a different
> > patch, for maintainability reasons.
> ...
> > --- 137,150 ----
> >           dnl to fall back to GNU NLS library.
> >
> >           if test $gt_api_version -ge 3; then
> > !           gt_revision_test_code='
> >   #ifndef __GNU_GETTEXT_SUPPORTED_REVISION
> >   #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 0 : -1)
> >   #endif
> > + changequote(,)dnl
> >   typedef int array [2 * (__GNU_GETTEXT_SUPPORTED_REVISION(0) >= 1) - 1];
> > ! changequote([,])dnl
> > ! '
> 
> The autoconf manual recommends against changequote when possible

Yes, and it is because of this recommendation that I was convinced to use
brackets instead of changequote in this place on 2005-07-28. And the result
was that, only two releases later, I got a quoting bug in gettext.m4 -
something which I otherwise haven't had in 5 years.

So, at least for me, changequote is more maintainable than brackets.
The third solution, the quadrigraphs, are not my choice either because
make it hard to copy&paste snippets from .m4 files to .c files or vice
versa.

> Furthermore, you
> used a raw m4 macro changequote; inside of autoconf, you should instead be
> using the m4sugar wrapper m4_changequote

m4_changequote is not documented in the autoconf manual (especially node
"Redefined M4 Macros").

> (as it is, how does this even 
> work?  m4sugar intentionally disables raw m4 macro names so that they will
> not be inadvertently expanded).

No idea why it works, but I verified that it works.

> One other thought - would it be worth making this code rely on
> AC_COMPUTE_INT, rather than open-coding your own checker based on typedef
> array size,

AC_COMPUTE_INT is more expensive: in a native build, it runs a program
(not just compiling a program), and in a cross-compile, it compiles 3
programs at least.

> to take advantage of the portability tricks that autoconf has 
> learned over the years about causing a guaranteed compile failure when
> checking for an integer result?

Hmm, which trick did I miss?

Bruno