Re: tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

On 24/09/2023, Peter Johansson <[email protected]> wrote:
> Hi Detlef and Nick,
>
> On 24/9/23 11:03, Nick Bowler wrote:
>> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
>> source code or documentation.
>
> My guess would be that the 3rd party is the autoconf archive because
> they provide both AX_CHECK_DEFINE and AC_CHECK_DEFINE
>
> http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_define.m4

OK, I see.

So, depending on the system you are running Autoconf on, GNU m4 may pre-
define __unix__ as an m4 macro which expands to the empty string.

Ignoring the fact that the this macro definition flagrantly disregards
the Autoconf reserved namespace... AC_CHECK_DEFINE here is quoting
inconsistently: $1 is double-quoted in the argument to AC_LANG_PROGRAM,
but it is only single-quoted in the arguments of AS_VAR_PUSHDEF and
AC_CACHE_CHECK.

So no amount of quoting at the call site will ever solve the problem for
Detlef.  We can quote __unix__ correctly for AC_LANG_PROGRAM, or we can
quote it for the other expansions, but never both at the same time.

If unwilling to fix the quoting issues within AC_CHECK_DEFINE, one way
to work around the problem is by using a quadrigraph to prevent __unix__
from being recognized as a macro, since quadrigraphs are removed only
after all macro processing is complete.  For example:

  AC_CHECK_DEFINE([__unix@&t@__], [...])

Another option is to redefine __unix__ as this GNU m4 feature seems
pretty unlikely to be useful in Autoconf, and even then it seems
unlikely to matter exactly what text __unix__ expands to:

  m4_ifdef([__unix__], [m4_define([__unix__], [[__unix__]])])dnl
  AC_CHECK_DEFINE([__unix__], [...])

I don't think there is any regression in Autoconf here, I don't see any
significant difference in behaviour between Autoconf 2.72c, 2.71 or
2.69.

Hope that helps,
  Nick