[cfe-commits] [PATCH] strnlen checker

[Lenny Maiorani]

On 02/25/2011 04:03 PM, Ted Kremenek wrote:
> On Feb 22, 2011, at 8:53 AM, Lenny Maiorani wrote:
>
>> On 02/21/2011 09:22 PM, Ted Kremenek wrote:
>>> I was looking at the test cases, and noticed the following diagnostics:
>>>
>>>    +  return strnlen(0, 3); // expected-warning{{Null pointer argument in call to byte string function}}
>>>
>>> and
>>>
>>>    +  return strnlen((char*)&&label, 3); // expected-warning{{Argument to byte string function is the address of the label 'label', which is not a null-terminated string}}
>>>
>>> I know you didn't write these diagnostics, but the term "byte string function" sounds very clinical, and not all that helpful.    It's certainly not a term I'm familiar with (even though I can decipher its meaning).  Do you think we should just say the name of the function instead of an opaque term like "byte string function"?
>>>
>> Ted,
>>
>> Thanks for committing my patches.
>>
>> I definitely agree that the term "byte string function" is a little ambiguous and possibly too proper. Changing that should be straight forward provided the CheckerContext knows the function in question. I assume it does and I just need to look into it.
> CStringChecker clearly knows the name of the function, since it dispatches off the function name in 'evalCall()'.
>
>> Expect a patch sometime soon.
> Sounds great!
Ted,

I am finally getting around to implementing this and the checkNonNull 
subchecker working for memcpy(), but the unit tests fail. This is 
because I am putting out the string 'Null pointer argument in call to X' 
where X is the name of the function. memcpy() has a variant defined as 
__memcpy_chk() so I cannot properly have an expected output in the unit 
test file because it changes. Is there a way to do this?

Also, looking around at other checkers, this does not seem to be the 
convention. Most of them simply describe the error in the description 
instead of describing the error including the name of the function. I am 
going to scrap this and instead attempt to make the description strings 
more meaningful. This will probably take some significant re-writing 
though. The architecture of the CStringChecker doesn't allow for some of 
the things I want to do.

Does this all make sense?

-Lenny