[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU Autoconf 2.71] testsuite: 10 11 12 14 37 92 236 238 239 240 293

From: Zack Weinberg
Subject: Re: [GNU Autoconf 2.71] testsuite: 10 11 12 14 37 92 236 238 239 240 293 299 397 430 431 432 433 434 435 436 437 438 439 440 509 514 failed
Date: Wed, 06 Jul 2022 16:51:06 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-719-gc39a70fa89-fm-20220629.002-gc39a70fa

On Sat, Jul 2, 2022, at 5:27 PM, Tom Lane wrote:
> I thought I'd respond to the question raised at [1] about which
> versions of m4 have this problem.
> I could build most versions on NetBSD 9.2/amd64,
> m4-1.4.7 shows largely the same set of failures as with 1.4.6
> With m4-1.4.8, there are just two failing tests

This is super helpful.  I had been assuming it was a bad Apple patch ultimately 
at fault, but I can reproduce more-or-less the same set of failures with m4 
1.4.[67] on my Linux workstation, in enough detail to investigate.

It turns out that there are three underlying issues.  One is a buggy regexp in 
Autoconf's testsuite that does not do what the comments say it does, causing 
any test that inspects m4 error messages to fail spuriously due to harmless 
variation in the wording between m4 versions.  I checked in commit 5d8a59e3 to 
fix this.

The other two issues are genuine problems with m4 1.4.6 and 1.4.7:

1) This command

    printf '%s\n' \
        'changequote(<,>)define(<T>,<>)dnl' \
        'define(<F>,<T(<traced>)>)dnl' \
        'm4wrap(<F>)dnl' \
    | m4 --debug=aflq --trace=T


    m4trace:stdin:3: -1- T(<traced>)

with m4 >= 1.4.8, but

    m4trace: -1- T(<traced>)

with 1.4.6 and 1.4.7.  The 'autom4te' wrapper script expects all 'm4trace:' 
lines to start with a file name and a line number, so it fails to parse the 
output.  This is the root cause of roughly half the testsuite failures.

2) This command

    printf '%s\n' \
        'changequote(<,>)define(<T>,<__line__>)dnl' \
        'T(<' \
        'abc' \
        '>)' \
    | m4

prints '2' with m4 >= 1.4.8 but '4' with 1.4.6 and 1.4.7.  That breaks the 
other half of the failing tests, which are all looking at autoconf diagnostic 
output and care about what line number is associated with a problem.

If it was just (2) I might have considered fixing it in the testsuite, but (1) 
is serious enough that I do think desupporting 1.4.6 and 1.4.7 is justified.

The NEWS file for m4 1.4.8 mentions both of these as deliberate changes:

# * Warnings and errors issued during macro expansion are now consistently
#   reported at the line where the macro name was detected, rather than
#   where the close parenthesis resides.  Text wrapped by `m4wrap' now
#   remembers the location that was in effect when m4wrap was invoked,
#   rather than changing to line 0 and the empty string for a file.

I have checked in commit 5d8a59e3 to make configure reject 1.4.6 and 1.4.7, and 
verified that, on my computer, I get 100% test successes with 1.4.8 and 1.4.19 
(again, this is Linux) after both patches are applied.  I also verified that 
configure does fail when 1.4.6 is the only version of m4 available.

The content of the patches is attached to this message.

> I soon found that GNU m4 is an incredibly fragile, system-dependent
> mess.

Yeah, with all the good will in the world, I don't think quadratic strstr() or 
lack of support for fseeko() are things that an application should be trying to 
work around.  Get the C library fixed instead!

> 1.4.18 does build, and we're back to
>    Subject: [GNU Autoconf 2.71] testsuite: 260 269 failed

I _would_ like to see the testsuite.log files from this run, specifically.  NB 
The test numbers change every time someone adds a new test, so it's not super 
helpful to know that "260 and 269" are failing consistently, with no further 

I'll follow up on the AC_HEADER_STDBOOL failures on macOS in a separate message 
(and possibly not for a few days).

> My recommendation would actually be to take out the check in m4.m4
> that purports to reject buggy strstr behavior --- if that's looking
> for something real, you couldn't tell it from the test suite.

It's a very real bug: the `index` builtin fails to find substrings that are 
actually present.  `index` (renamed `m4_index` for namespace cleanliness) is 
used in dozens of places in autoconf's code, so if the testsuite passes with 
the bug present, it's only by dumb luck.


Attachment: 0002-Require-GNU-M4-1.4.8-or-later.patch
Description: Text Data

Attachment: 0001-testsuite-Handle-balanced-ASCII-quotes-correctly-in-.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]