Actually, that's not a clang bug; my test case had a typo. It's still a

case where clang is complaining about code that's OK, it's just not OK
in a way that lets clang determine that it is.

svn path=/trunk/; revision=50196
This commit is contained in:
Guy Harris 2013-06-27 19:14:41 +00:00
parent 99013aefa8
commit b7a3865c91
1 changed files with 7 additions and 2 deletions

View File

@ -324,8 +324,13 @@ if [ ! -f glib-$GLIB_VERSION-done ] ; then
# "#define.*MACOSX" in /usr/include/ffi/fficonfig.h, explictly
# define it.
#
# While we're at it, suppress -Wformat-nonliteral to avoid a clang
# bug where it issues bogus warnings.
# While we're at it, suppress -Wformat-nonliteral to avoid a case
# where clang's stricter rules on when not to complain about
# non-literal format arguments cause it to complain about code
# that's safe but it wasn't told that. See my comment #25 in
# GNOME bug 691608:
#
# https://bugzilla.gnome.org/show_bug.cgi?id=691608#c25
#
# First, determine where the system include files are. (It's not
# necessarily /usr/include.)