[LLVMbugs] [Bug 10284] New: False positives for null pointer dereferences with glib/gtk+

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Jul 6 07:30:20 PDT 2011


http://llvm.org/bugs/show_bug.cgi?id=10284

           Summary: False positives for null pointer dereferences with
                    glib/gtk+
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: kjartan.maraas at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm seeing a huge amount of false positives here when building gtk+

One assumption within glib/gtk+ that the analyzer doesn't pick up is that priv
pointers can never be NULL. They are set early on in the various _init
functions for the different widgets and then not set again.

It also looks like the analyzer doesn't understand the parameter checking in
glib with functions like this generating warnings:

void
1837    _gtk_tree_menu_set_row_span_column (GtkTreeMenu *menu,
1838    gint row_span)
1839    {
1840    GtkTreeMenuPrivate *priv;
1841    
1842    g_return_if_fail (GTK_IS_TREE_MENU (menu));
1843    
1844    priv = menu->priv;

Access to field 'priv' results in a dereference of a null pointer (loaded from
variable 'menu')
1845    

the function will return in g_return_if_fail() if menu is NULL. Also as
mentioned above menu->priv should never be NULL, and the only way to make it be
so is to intentionally abuse the API and feed NULL pointers to the public
functions. This is not something that the glib/gtk+ developers feel is worth
spending resources on fixing just to silence the clang-analyzer.

Is there a way to mark certain functions / patterns as excluded like there is
for valgrind with supression files? Or will this have to be fixed in the
analyzer itself?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list