Why does scan-build disable check for uninit values?

Hi

I’ve noticed that scan-build in the latest version of the checker (137) disables the check for uninit values (-warn-uninit-values).
Is there a reason behind that?

Thank you,
Cristi

In the static analyzer, checking for uninitialized values, just as with checking for null dereferences, is done as part of the core path-sensitive logic used for -checker-cfref and -checker-simple. It isn't controlled by -warn-uninit-values.

The -warn-uninit-values option performs a fast check for uses of uninitialized values that is similar to GCC's -Wuninitialized. It should be thought of as a cheap check that can be used (one day) as a compiler warning rather than a deep check done by the static analyzer. The checking for uninitialized values done by the static analyzer is far more precise.

Some of these options should probably be renamed to avoid such confusion.

My confusion was actually caused by the different output of “-checker-cfref” vs “-warn-uninit-values”.

In the warning below shouldn’t clang say “Pass-by-value argument in function is uninitialized”?
English is not my native language so I may be wrong but I tend to equate “undefined” with “undeclared” (as in lacking definition).

diciu$ ~/Downloads/checker-137/clang -x c test.c -checker-cfref
ANALYZE: test.c main
test.c:6:2: warning: Pass-by-value argument in function is undefined.
strcpy(t, g);
^ ~
1 diagnostic generated.

diciu$ ~/Downloads/checker-137/clang -x c test.c -warn-uninit-values
test.c:6:9: warning: use of uninitialized variable
strcpy(t, g);
^
test.c:6:12: warning: use of uninitialized variable
strcpy(t, g);
^
2 diagnostics generated.

test.c is:

#include <string.h>

int main()
{
char * t, * g;
strcpy(t, g);

return 0;
}

Oh, nevermind, I get it.
“Pass-by-value argument in function is undefined” probably refers to the value pointed to by the char pointer as being undefined, which it is.

That’s it. I used the terminology “undefined” because undefined values can come from other sources other than uninitialized variables. The warning, however, could probably be worded a little more clearly.

Hi All

I’m using clang as a parser for another project (ie I have my own Actions implementation) and I get an assert failure on the following code:

int a;
int main()
{
return ::a;
}

The assertion text reads:

assertion “CachedTokens[CachedLexPos-1].getLocation() == Tok.getAnnotationEndLoc() && “The annotation should be until the most recent cached token”” failed: file “PPCaching.cpp”, line 95

Does anyone know what this is? Also, can I turn off caching of tokens if I’m not worried about speed?

Cheers, John

A little more info:

AnnotatePreviousCachedTokens() is called from AnnotateCachedTokens() which is called from TryAnnotateTypeOrScopeToken() in the last clause (dealing with C++ scope followed by non-typename).

AnnotatePreviousCachedTokens() requires the range of the supplied annotation token to end at the last pasrsed token. This range is being set from the source range of the C++ scope.

John Graley wrote:

A little more info:

AnnotatePreviousCachedTokens() is called from AnnotateCachedTokens()
which is called from TryAnnotateTypeOrScopeToken() in the last clause
(dealing with C++ scope followed by non-typename).

AnnotatePreviousCachedTokens() requires the range of the supplied
annotation token to end at the last pasrsed token. This range is being
set from the source range of the C++ scope.

I can reproduce the bug, but this stuff is Argiris's baby, and he's
rarely available on weekends.

Sebastian

This should work now, please let me know if you see similar asserts,

-Chris