| Commit message (Collapse) | Author | Age | Files | Lines | |
|---|---|---|---|---|---|
| * | [analyzer] Assume new returns non-null even under -fno-exceptions | Pavel Labath | 2013-08-28 | 1 | -25/+7 |
| | | | | | | | | | | | | | | | | | | | Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452 | ||||
| * | [analyzer] Assume 'new' never returns NULL if it could throw an exception. | Jordan Rose | 2012-10-20 | 1 | -0/+71 |
| This is actually required by the C++ standard in [basic.stc.dynamic.allocation]p3: If an allocation function declared with a non-throwing exception-specification fails to allocate storage, it shall return a null pointer. Any other allocation function that fails to allocate storage shall indicate failure only by throwing an exception of a type that would match a handler of type std::bad_alloc. We don't bother checking for the specific exception type, but just go off the operator new prototype. This should help with a certain class of lazy initalization false positives. <rdar://problem/12115221> llvm-svn: 166363 | |||||
 |
index : bcm5719-llvm | |
| Project Ortega BCM5719 LLVM | Raptor Computing Systems |
| summaryrefslogtreecommitdiffstats |
|