[cfe-dev] Design draft: improving detection of uninitialized arguments (the CallAndMessageChecker)

[Per Viberg]

Hi,

Here is a proposed design draft to implement an extension of the check that warns for uninitialized arguments.
Any objections/opinions on this solution?.

Primarily looking for comments on: interfaces I plan to use and if it's correct to put the change in CallAndMessageChecker::checkPreCall etc.

The new feature is to find arguments that are pointers to uninitialized variables, i.e. detect this:

void doStuff(const int *p);
void f(void);

void f(void) {
      int x;
      doStuff(&x);  // ← warning "Function call argument is a pointer to uninitialized value"
}

I propose this design:

1. Extend the CallAndMessageChecker::checkPreCall to analyse the parameters in conjunction with arguments.
2. If argument is declared as const Type*,
3. but corresponding parameter is pointer to undefined value in current function call,
3. then generate warning "Function call argument is a pointer to uninitialized value"

I am going to use mainly the following interfaces:
SVal::getAs<loc::MemRegionVal>()
MemRegionVal::getRegion()
CheckerContext::&getState()
SVal::isUndef()
QualType::getTypePtr()
Type::getPointeeType()
QualType::isConstQualified()
FunctionDecl::getParamDecl(unsigned i)

any objects/opinions on the design?

cheers!
/Per


.......................................................................................................................
Per Viberg Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden
Phone:    +46 (0)8 402 79 00
Mobile:    +46 (0)70 912 42 52
E-mail:     Per.Viberg at evidente.se<mailto:Per.Viberg at evidente.se>

www.evidente.se<http://www.evidente.se>
This e-mail, which might contain confidential information, is addressed to the above stated person/company. If you are not the correct addressee, employee or in any other way the person concerned, please notify the sender immediately. At the same time, please delete this e-mail and destroy any prints. Thank You.
________________________________
Från: Per Viberg
Skickat: den 14 februari 2014 13:41
Till: Clang Dev ‎[cfe-dev at cs.uiuc.edu]‎
Ämne: improving detection of uninitialized arguments (the CallAndMessageChecker)


Hi,

I'm looking into extending the check that warns for uninitialized arguments. Below I've described what should be detected. Any opinions on if it's a useful check or potential problems/drawbacks with it?.

Check: should this be detected as a warning for uninitialized argument?:"warning: Function call argument is an uninitialized value"

void doStuff(const int *p);
void f(void);

void f(void) {
      int x;
      doStuff(&x);  // ← warning?
}

My rationale behind the warning:
1. it's not possible to write to *p, because it's of type const
2. content of *p is uninitialized stack value, and shouldn't be used.
3. the value of p is of no interest, since it's an address of an stack variable.

if any of the above criteria are not fulfilled, then no warning. Thus the function prototype must state pointer to const for the argument, the variable that the function is called with must be address of local/stack variable.

currently, only this is detected:

void doStuff2(int p);
void g(void);

void g(void) {
      int y;
      doStuff2(y);  // warning: Function call argument is an uninitialized value


/Per



.......................................................................................................................
Per Viberg Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden
Phone:    +46 (0)8 402 79 00
Mobile:    +46 (0)70 912 42 52
E-mail:     Per.Viberg at evidente.se<mailto:Per.Viberg at evidente.se>

www.evidente.se<http://www.evidente.se>
This e-mail, which might contain confidential information, is addressed to the above stated person/company. If you are not the correct addressee, employee or in any other way the person concerned, please notify the sender immediately. At the same time, please delete this e-mail and destroy any prints. Thank You.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140219/7644f4d9/attachment.html>