Hi David,
Sorry I missed out on your answer about the operator new patch on the IRC.
Should I submit the first bit of the operator new patch ? Putting aside for
now fixing the
"uninitialized value" that accompanies "null deref" of nothrow new variants
?
About generalizing tests to C++, I'll soon have a second batch of similar
size ready,
probably by Monday. I try to find exactly one "real" bug to build each
batch around, to not simply
have a collection of C made C++ friendly.
A few questions on that point.
Test gcc.dg/analyzer/pr103892.c requires -O2.
As such the IPA generated from C and C++ differ,
C++ optimization cuts off function argstr_get_word from the IPA,
hence reducing the number of SN nodes from the SG.
This lesser number of SN is sufficient to make the analysis trips over
being too-complex.
The current formula for that upper limit is
limit = m_sg.num_nodes () * param_analyzer_bb_explosion_factor;
Thus shorter programs - such as the analyzer tests - are more likely to
be diagnosed as too complex. To avoid false positives perhaps we should
add an offset, so that short SG get their chance ?
This is just a tweak, and pr103892.c could as well be discarded for C++,
divergent IPA between C and C++ are unavoidable at some point, and some
tests won't make the transition anyway.
In gcc.dg/analyzer/malloc-1.c:test_50{b,c}, C++ is imprecise as of the
memory freed.
void test_50b (void)
{
free ((void *) test_50a); /* { dg-warning "'free' of '&test_50a' which
points to memory not on the heap \\\[CWE-590\\\]" } */
/* { dg-bogus "'free' of 'test_50a' which points to memory not on the
heap \\\[CWE-590\\\]" "c++ lacks precision of freed memory" { xfail c++ }
.-1 } */
}
void test_50c (void)
{
my_label:
free (&&my_label); /* { dg-warning "'free' of '&my_label' which points to
memory not on the heap \\\[CWE-590\\\]" } */
/* { dg-warning "'free' of '&& my_label' which points to memory not on
the heap \\\[CWE-590\\\]" "" { xfail c++ } .-1 } */
}
What do you think of this ?
I've checked malloc_state_machine::handle_free_of_non_heap, arg and
diag_arg are strictly equal.
There might be something to be done with how a tree is transformed into a
diagnostic tree by get_diagnostic_tree,
but I'll wait for your feedback first.
Test gcc.dg/analyzer/pr94362-1.c actually has an additional null_deref
warning in C++, which is not affected by exceptions
or optimizations. I will keep updated on that one. Note that no warnings
are emitted for this test in C.
analyzer/pr94362-1.c: In function ‘const EVP_PKEY_ASN1_METHOD*
EVP_PKEY_asn1_find_str(ENGINE**, const char*, int)’:
analyzer/pr94362-1.c:55:16: warning: dereference of NULL ‘ameth’ [CWE-476]
[-Wanalyzer-null-dereference]
analyzer/pr94362-1.c:39:29: note: (1) entry to ‘EVP_PKEY_asn1_find_str’
analyzer/pr94362-1.c:42:31: note: (2) ‘ameth’ is NULL
analyzer/pr94362-1.c:53:43: note: (3) following ‘true’ branch...
analyzer/pr94362-1.c:54:31: note: (4) ...to here
analyzer/pr94362-1.c:54:31: note: (5) calling ‘EVP_PKEY_asn1_get0’ from
‘EVP_PKEY_asn1_find_str’
analyzer/pr94362-1.c:29:29: note: (6) entry to ‘EVP_PKEY_asn1_get0’
analyzer/pr94362-1.c:32:53: note: (7) ‘0’ is NULL
analyzer/pr94362-1.c:54:31: note: (8) returning to ‘EVP_PKEY_asn1_find_str’
from ‘EVP_PKEY_asn1_get0’
analyzer/pr94362-1.c:54:31: note: (9) ‘ameth’ is NULL
analyzer/pr94362-1.c:55:16: note: (10) dereference of NULL ‘ameth’
Cheers,
Benjamin.
