bug-autoconf
[Top][All Lists]
Advanced

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

Re: autoconf 2.63b: wrong macro expansion order


From: Eric Blake
Subject: Re: autoconf 2.63b: wrong macro expansion order
Date: Sun, 05 Apr 2009 07:46:06 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Andreas Schwab on 4/4/2009 5:02 AM:
> With the following input autoconf 2.63b expands macros out of order:

Let's narrow it down to something a little more abstract, so there is less
text to wade through:

$ cat foo
m4_init
m4_divert_push([0])
m4_define([a], [0])dnl _AC_COMPILER_EXEEXT
m4_defun([b], [1
m4_expand_once([a])
2])dnl AC_PROG_CC
m4_defun([c], [m4_require([b])])dnl AC_LANG_COMPILER(C)
m4_define([d], [c])dnl AC_LANG_COMPILER
m4_defun([e], [m4_require([c], [d])])dnl AC_LANG_COMPILER_REQUIRE
m4_defun([f], [e])dnl AC_COMPILE_IFELSE
m4_defun([g], [3
f
4])dnl FOO
m4_defun([h], [5
b
6
g
7])dnl BAR
h
m4_divert_pop
$ m4 -I autoconf-2.63/lib m4sugar/m4sugar.m4 foo


5
1
0
2
6
3

4
7
$ m4 -I autoconf-2.63b/lib m4sugar/m4sugar.m4 foo

1

2

5
1
0
2
6
3

4
7
$

In 2.63, AC_PROG_CC (1,0,2) was output in-place during BAR, then when FOO
encountered the AC_REQUIRE, AC_PROG_CC was skipped since it had already
been expanded.  In this case, there were no out-of-order dependencies, but
the premise of AC_REQUIRE was violated in that AC_PROG_CC was not hoisted
to occur prior to the outermost AC_DEFUN (that is, 5 was output before 1).

In 2.63b, the premise of AC_REQUIRE is recognized - by requiring
AC_PROG_CC, we are guaranteed that its body will be hoisted prior to the
outermost AC_DEFUN'd macro.  However, we have already expanded the
m4_expand_once text, so while the 1,2 is output twice, the 0 is not.

In one sense, it sounds like KDE was relying on the 2.63
expand-before-require bug in order to insert text prior to the expansion
of AC_PROG_CC, and now that 2.63b is properly hoisting the AC_REQUIRE call
(albeit with duplicated text), that it is interfering with their exploit.

But if that's the case, why not explicitly state those dependencies:

$ cat bar
m4_init
m4_divert_push([0])
m4_define([a], [0])dnl _AC_COMPILER_EXEEXT
m4_defun([b], [1
m4_expand_once([a])
2])dnl AC_PROG_CC
m4_defun([c], [m4_require([b])])dnl AC_LANG_COMPILER(C)
m4_define([d], [c])dnl AC_LANG_COMPILER
m4_defun([e], [m4_require([c], [d])])dnl AC_LANG_COMPILER_REQUIRE
m4_defun([f], [e])dnl AC_COMPILE_IFELSE
m4_defun([g], [3
f
4])dnl FOO
m4_defun([h], [m4_require([i])
m4_require([b])
6
g
7])dnl BAR
m4_defun([i], [5])dnl KDE's desired pre-compiler text
h
m4_divert_pop
$ m4 -I autoconf-2.63/lib m4sugar/m4sugar.m4 foo

5
1
0
2



6
3

4
7
$ m4 -I autoconf-2.63b/lib m4sugar/m4sugar.m4 foo

5
1
0
2



6
3

4
7
$

- --
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

iEYEARECAAYFAknYth4ACgkQ84KuGfSFAYBeLgCeKzoqgZ8GWgqXPyfAEsOPjOWZ
0l0AniX/j+LCImoGwYo4FCM6Fo2QMxTv
=HkJQ
-----END PGP SIGNATURE-----




reply via email to

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