autoconf-patches
[Top][All Lists]
Advanced

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

Re: Debian-specific Autoconf patches


From: Paul Eggert
Subject: Re: Debian-specific Autoconf patches
Date: Wed, 31 May 2006 12:57:48 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

> I guess you're simply right and I'm over-cautious.

I wish it were that simple!  We're both trying to predict the future,
and neither of knows who will be right.  (We might both be wrong. :-)
It is a bit funny, though, since normally I tend to be the
conservative one about compatibility and whatnot and others (like Akim
:-) are more willing to push the envelope.

> http://lists.gnu.org/archive/html/autoconf/2006-05/msg00118.html

Sorry, I don't have much intuition about this one.  It's fine with me
if you install this, or if you omit it.

> - here document braced parameter expansion bug in ksh93f
> (fixed in ksh93g 98-04-30):
> http://lists.gnu.org/archive/html/autoconf-patches/2006-05/msg00122.html

Ah, I didn't know the ksh93g fix.  I'll add that to the Autoconf manual.

This change can wait until after 2.60.  The problem here is
readability, not functionality.  Stepan is thinking of altering the
"better shell" algorithm, which would be a bit risky at this stage.
Now that we know a bit more about the bug, I think it unlikely that
we'll run into it elsewhere in Autoconf-generated code, since the
other here-documents that Autoconf generates either are short, or
don't use ${...}.

> http://lists.gnu.org/archive/html/autoconf/2006-05/msg00127.html
> Do we want this before 2.60?  If yes, a working patch would be needed.

This can wait.  The change is OK in principle, but it isn't crucial.

> If I had to decide (or nothing happens on these matters), I'd apply
> the first, think some more about the second, skip the third, and go
> ahead with 2.59d.

Sounds good, except I don't think you need to think more about the
second, and that we can just go ahead as-is.

I thought about other ways to break the _AC_DO_ECHO change and came up
with one more scenario involving underquoted code.  I installed this:

2006-05-31  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (Here-Documents): Mention that the ksh bug
        was fixed in ksh93g; reported by Ralf Wildenhues.
        * lib/autoconf/general.m4 (_AC_DO_ECHO): Be even more conservative
        about quoting the case statement, just in case.

2006-05-31  Stepan Kasal  <address@hidden>

        * doc/autoconf.texi (Particular Programs) <AC_PROG_MKDIR_P>:
        Document that ${MKDIR_P} understands --.

--- doc/autoconf.texi   27 May 2006 22:22:01 -0000      1.1029
+++ doc/autoconf.texi   31 May 2006 19:51:39 -0000      1.1031
@@ -3546,8 +3546,10 @@ This macro is related to the @code{AS_MK
 in M4sh}), but it sets an output variable intended for use in other
 files, whereas @code{AS_MKDIR_P} is intended for use in scripts like
 @command{configure}.  Also, @code{AS_MKDIR_P} does not accept options,
-but @code{MKDIR_P} can use the @option{-m} option, e.g., a makefile might
-invoke @code{$(MKDIR_P) -m 0 dir} to create an inaccessible directory.
+but @code{MKDIR_P} supports the @option{-m} option, e.g., a makefile
+might invoke @code{$(MKDIR_P) -m 0 dir} to create an inaccessible
+directory, and conversely a makefile should use @code{$(MKDIR_P) --
+$(FOO)} if @var{FOO} might yield a value that begins with @samp{-}.
 Finally, @code{AS_MKDIR_P} does not check for race condition
 vulnerability, whereas @code{AC_PROG_MKDIR_P} does.
 @end defmac
@@ -10796,7 +10798,9 @@ expansion @address@hidden@}} that crosses a
 within a here-document.  If the closing brace does not lie on the boundary,
 the failure is silent and the variable expansion will be empty, otherwise
 the shell will report a bad substitution.  This bug can usually be worked
-around by omitting the braces: @code{$var}.
+around by omitting the braces: @code{$var}.  The bug was fixed in
address@hidden (1998-04-30) but as of 2006 many operating systems were
+still shipping older versions with the bug.
 
 Some shells can be extremely inefficient when there are a lot of
 here-documents inside a single statement.  For instance if your
--- lib/autoconf/general.m4     31 May 2006 01:28:06 -0000      1.923
+++ lib/autoconf/general.m4     31 May 2006 19:47:07 -0000
@@ -2152,11 +2152,18 @@ AC_DEFUN([_AC_DO_ECHO],
 dnl If the string contains '"', '`', or '\', then just echo it rather
 dnl than expanding it.  This is a hack, but it is safer, while also
 dnl typically expanding simple substrings like '$CC', which is what we want.
+dnl
 dnl The rest of this macro body is quoted, to work around misuses like
 dnl `AC_CHECK_FUNC(sigblock, , AC_CHECK_LIB(bsd, sigblock))',
 dnl which underquotes the 3rd arg and would misbehave if we didn't quote here.
-[case $ac_try in #(
-  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;; #(
+dnl The "(($ac_try" instead of $ac_try avoids problems with even-worse
+dnl underquoting misuses, such as
+dnl `AC_CHECK_FUNC(foo, , AC_CHECK_LIB(a, foo, , AC_CHECK_LIB(b, foo)))'.
+dnl We normally wouldn't bother with this kind of workaround for invalid code
+dnl but this change was put in just before Autoconf 2.60 and we wanted to
+dnl minimize the integration hassle.
+[case "(($ac_try" in
+  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
   *) ac_try_echo=$ac_try;;
 esac
 eval "echo \"\$as_me:$LINENO: $ac_try_echo\""]])




reply via email to

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