llvm-svn: 45382

llvm-svn: 45381

and OwningPtr instead of constructing only after all of sema is done.  This
has a couple of effects:
1. it fixes memory leaks from all the error cases in sema
2. it simplifies the code significantly.

The cost of this is that the error case now new's and delete's an expr where
it did not before, but we don't care about the perf of the error case.

llvm-svn: 45380

are due to arrive.

llvm-svn: 45244

llvm-svn: 45239

llvm-svn: 45235

llvm-svn: 45234

Fixe bogus error for variable argument methods. Sema::ObjcGetTypeForMethodDefinition() wasn't preserving the isVariadic boolean. Another fix is to avoid synthsizing the function decl entirely, however this is a separate issue that I don't want to deal with now. Also added a FIXME to Sema::CheckFunctionCall(), which is currently emitting a bogus warning.

llvm-svn: 45146

following hold:

(1) A vprintf-like function is called that takes the argument list via a
    via_list argument.

(2) The format string is a non-literal that is the parameter value of
    the enclosing function, e.g:
    
    void logmessage(const char *fmt,...) { 
      va_list ap;
      va_start(ap,fmt);
      fprintf(fmt,ap);  // Do not emit a warning.
    }
    
In the future this special case will be enhanced to consult the "format"
attribute attached to a function declaration instead of just allowing a blank
check for all function parameters to be used as format strings to vprintf-like
functions. This will happen when more support for attributes becomes
available.

llvm-svn: 45114

llvm-svn: 45110

llvm-svn: 44576

GCC has an extension where the left hand side of the ? : operator can be omitted. Handle this in a few more places.

llvm-svn: 44462

floating-point literals that are represented exactly by the APFloat in
FloatingLiteral. For such literals, we do not emit a warning since such checks are
often performed in real code to see if a variable has changed from its original
value. This heuristic clearly can lead to false negatives, but the hope is it will
significantly reduce false positives to help make the compiler flag more useful.

llvm-svn: 44424

Moved utility functions IgnoreParen and friends to be static inline functions
defined in SemaUtil.h.

Added SemaUtil.h to Xcode project.

llvm-svn: 44312

printf format strings.  Added type checking to see if the matching
width/precision argument was of type 'int'.

Thanks to Anders Carlsson for reporting this missing feature.

llvm-svn: 42933

llvm-svn: 42917

specifiers.

llvm-svn: 42886

llvm-svn: 41611

variables that have a pointer type, or arrays that contain pointers.

This fixes a crash on the following code:

int *h[3];

int **foo(int i)
{
   return &(h[i]);
}

This bug was reported by Keith Bauer (thanks!).

llvm-svn: 41546

implicit casts from T to T& at the topmost part of the return-value expression.

This checking may be needed within EvalAddr later on.  We'll wait until
test cases show this kind of logic is necessary (as more C++ features are
implemented in clang).

llvm-svn: 41493

llvm-svn: 41454

t.c:3:9: warning: invalid conversion '%B'
printf("%B\a\n", p);
~~~~~~  ^

Don't beep the console or print the newline.

llvm-svn: 41453

llvm-svn: 41398

llvm-svn: 41396

to getBase and getIdx.  getBase and getIdx now return a "normalized" view
of the expression (e.g., always "A[4]" instead of possibly "4[A]").  getLHS
and getRHS return the expressions with syntactic fidelity to the original
source code.

Also modified client code of ArraySubscriptExpr, including the AST dumper
and pretty printer, the return-stack value checker, and the LLVM code
generator.

llvm-svn: 41180

"return of stack addresses."  ParseReturnStmt now calls CheckReturnStackAddr
to determine if the expression in the return statement evaluates to an
address of a stack variable.  If so, we issue a warning. 

llvm-svn: 41141

llvm-svn: 41140

llvm-svn: 41136

family of functions.  Previous functionality only included checking to
see if the format string was a string literal.  Now we check parse the
format string (if it is a literal) and perform the following checks:

(1) Warn if: number conversions (e.g. "%d") != number data arguments.

(2) Warn about missing format strings  (e.g., "printf()").

(3) Warn if the format string is not a string literal.

(4) Warn about the use se of '%n' conversion.  This conversion is
    discouraged for security reasons.

(5) Warn about malformed conversions.  For example '%;', '%v'; these
    are not valid.

(6) Warn about empty format strings; e.g. printf("").  Although these
    can be optimized away by the compiler, they can be indicative of
    broken programmer logic.  We may need to add additional support to
    see when such cases occur within macro expansion to avoid false
    positives.

(7) Warn if the string literal is wide; e.g. L"%d".

(8) Warn if we detect a '\0' character WITHIN the format string.

Test cases are included.

llvm-svn: 41076

by CheckPrintfArguments to determine if a given printf function
accepts a va_arg argument.

llvm-svn: 41008

"I've coded up some support in clang to flag warnings for non-constant format strings used in calls to printf-like functions (all the functions listed in "man fprintf").  Non-constant format strings are a source of many security exploits in C/C++ programs, and I believe are currently detected by gcc using the flag -Wformat-nonliteral."

llvm-svn: 41003