[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 2.62 AT_SETUP limitations
Re: 2.62 AT_SETUP limitations
Tue, 22 Apr 2008 06:45:26 -0600
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20080213 Thunderbird/220.127.116.11 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
According to Joel E. Denny on 4/22/2008 2:36 AM:
| According to Autoconf 2.62's manual, AT_SETUP no longer allows unbalanced
| parentheses to appear in test case titles. This regression breaks CVS
| Bison's test suite, which worked fine with 2.61, and it seems like an
| unnecessary limitation.
Unfortunately, it was a necessary implementation artifact in order to
fix the more common bug of , quadrigraphs, and underquoted space after
comma resulting in the 'ok' message appearing in the wrong column of
| Output file name: (
Yes, it is a behavioral regression; but at least we documented this as an
| The second test case title above now causes "make testsuite" to produce
| this error:
| /usr/bin/m4:output.at:189: ERROR: end of file in string
| autom4te: /usr/bin/m4 failed with exit status: 1
| make: *** [testsuite] Error 1
Yes, because this is a case of unbalanced ().
| Instead of adding the precondition "no unbalanced parentheses" to
| AT_SETUP, why not add the precondition "the argument must expand properly
Because AT_SETUP now uses the newly documented m4_expand macro, which in
turn REQUIRES balanced () because it temporarily uses
m4_changequote([(],[)]) to force preservation of unquoted space after
comma. In other words, now that () is participating as quote characters,
it must occur in a balanced manner, regardless of the level of 
surrounding the usage (since the temporary changequote means that  is
not quoting the () usage). My thinking at the time of implementing this
restriction was that the user was unlikely to use unbalanced () in a test
title, but you've proven my guess wrong.
| In general, I seem to able to write m4 macros that can reliably
| manipulate any user arguments that meet the latter precondition. Given
| autom4te's quadrigraphs for brackets, the user is then never limited on
| what strings he can specify to my macros. I think this should be possible
| with AT_SETUP as well.
Sounds like we need to add a new quadrigraph for ( and ), then. Any
suggestions for the two middle characters?
| For example:
| AT_SETUP([[Output file name: (]])
Won't work, since m4_expand needs balanced ().
| Or if the user needs to pass in a macro for expansion:
| m4_define([test_char], [[(]])
| AT_SETUP([[Output file name: ]test_char])
Still won't work, since m4_expand expands test_char in advance to
determine how long the output line will be, and in expanding it, sees an
| AT_SETUP can use m4_dquote($1) to initially expand the argument. If $1
| meets the precondition, this will expand to a perfectly quoted string that
| can be passed to, for example, m4_bpatsubst for shell-escaping. The
| result of m4_bpatsubst can be placed in the output shell script.
m4_bpatsubst is dirt slow compared to m4_expand; I already spent quite a
bit of effort in speeding up autom4te behavior in 2.62 above what it
previously was. And it is not shell-escaping that is the problem, but
determining the width of the resulting string. Really, the problem is
that there is no way to determine whether $1 is safe to expand, short of
expanding $1; thus, if it was not safe, you've already screwed up the
state of the m4 parsing. So we chose to document this as a limitation of
AT_SETUP strings instead.
| Is this precondition believed to be insufficient? Or is the trouble that
| it breaks backward compatibility? In the latter case, can we add an
| AT_SETUP_ROBUST that can handle unbalanced parentheses?
I'm leaning more to the quadrigraph option. In the meantime, you will
just have to work around the limitation by choosing a test title that
expands to a safe string (for example, see
starting at line 398, for how autoconf tests funny test titles, but prints
an English name in AT_SETUP rather than the actual funny title; also, this
would be where we would add a test using a quadrigraph to ensure that your
desired usage pattern is restored in autoconf 2.63).
Thank you for the report.
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Re: 2.62 AT_SETUP limitations, Akim Demaille, 2008/04/24