autoconf
[Top][All Lists]
Advanced

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

Re: Dereference of undefined pointer value in conftest.c


From: Eric Blake
Subject: Re: Dereference of undefined pointer value in conftest.c
Date: Sun, 06 Dec 2009 19:27:50 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

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

According to Ruben Safir on 12/6/2009 7:15 PM:
> On Sun, Dec 06, 2009 at 09:10:47PM +0100, Tomas Carnecky wrote:
>> I just ran the clang static analyzer on the xserver configure script and
>> it reported a few issues. Most of them were dead assignments/increments,
>> but there also was one dereference of an undefined pointer value. I
>> don't know which tests the conftest.c belongs to, but I doubt it's to
>> test if an application can safely write to unknown memory ;). The test
>> contains the following code:
>>
>> { /* SCO 3.2v4 cc rejects this. */
>>     char *t;
>>     char const *s = 0 ? (char *) 0 : (char const *) 0;
>>     *t++ = 0; /* <<< t is undefined! */
>>     if (s) return 0;
>> }
>>
>> Tell me if you want more informations or if you are interested in the
>> full report from clang.
>>
>> tom
>>
> 
> 
> This whole piece of code looks screwed up to me.  Why would a trinary
> operator try to return anonymous nulls?

Both of you are missing the point of this test.

$ git grep -B30 't\+\+ = 0'

shows that it is part of:

> lib/autoconf/c.m4-AC_DEFUN([AC_C_CONST],
> lib/autoconf/c.m4-[AC_CACHE_CHECK([for an ANSI C-conforming const], 
> ac_cv_c_const,
> lib/autoconf/c.m4-[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([],

in other words, it is a compile-only test, to see if the compiler supports
a compliant implementation of const.  The code in question will never be
run, so a ternary operator returning NULL, or dead code, or even
dereferencing uninitialized variables, don't matter.  All that matters is
that the compiler is properly type-safe and properly honors const.

That said, if there are some simple things we can to do to make various
compilers less likely to complain about suspicious concepts while still
getting correct answers about detecting broken compilers, then propose a
patch.  But for now, I'm not worried about changing anything.

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

iEYEARECAAYFAkscaCYACgkQ84KuGfSFAYCmaACfRgyFPRI6qnUcN/EIW4R04VVu
IWIAoMmuAe9xhHD2g3Y/hUj0WTUI13ft
=7i3k
-----END PGP SIGNATURE-----




reply via email to

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