[splint-discuss] Passed storage is stack

Carsten.Agger at tietoenator.com Carsten.Agger at tietoenator.com
Wed Apr 23 23:37:22 PDT 2008



> 
>> Here's another splint warning pattern which occurs very 
>> frequently in the code I'm reviewing:
>> 
>> struct_type s;
>> member_type m;
>> 
>> s = << ... >>
>> 
>> s.m = &m;
>> 
>> f(..., ..., &s, ..., ...);
> 
> 
>I believe this is a bug (or more precisely a missing feature): there's
>no annotation currently supported by Splint to tell it that this
>parameter to f can point to stack-allocated storage. That's what should
>be annotated, IMO - the formal parameter in the declaration of f.
>
>That is, what we want is something like:
>
>	int f(/*@notkept@*/ int *p);

Thanks a lot! Yes, it would seem like a bug, because if splint assumes the storage is kept, 
the other solution (of malloc'ing and subsequently free'ing) isn't really better, so to 
be consistent, splint should complain in *both* cases - and it doesn't.

As it happens, the problem seems to arise mainly with structs with pointer members allocated
on the stack - splint does not complain about the struct s itself (which is also stack), only 
s.m.


>That's what happens when you use a free, open-source code analyzer
>that's been largely unmaintained for years: you find bugs. Static code
>analysis is a hard problem, which is why there are fancy commercial
>products. I'm afraid your choices are basically to put up with the error
>(or with a less-satisfactory solution such as disabling compmempass
>around the offending line), fix Splint yourself, or use another code
>analyzer.

Unfortunately, I can't decide which code analyzer to use, this is a more strategic decision in 
the project - so I'll have to find a way around.

Thanks for the input, anyway!

br
Carsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3733 bytes
Desc: not available
Url : http://www.cs.virginia.edu/pipermail/splint-discuss/attachments/20080424/e68d6078/attachment-0001.bin 


More information about the splint-discuss mailing list