Lines 370 et seq: // If we're compiling with exceptions enabled, and this allocation function // is not declared as non-throwing, failures /must/ be signalled by // exceptions, and thus the return value will never be NULL.
This comment is outdated after your patch; you should update it. > even with > -fno-exceptions, the generated code never tests for null (and would segfault > if > the opeator actually happened to return null). I like this patch, but I think it makes it even more important that Clang implement GCC's -fcheck-new semantics as soon as possible. Right now, Clang doesn't even treat that option as silently ignored; it barfs out a warning. The motivation for -fcheck-new is: malloc(hugenumber) can return NULL therefore new char[hugenumber] can return NULL (either via a not-quite-conforming user-defined operator new, or via an implementation-defined operator new under -fno-exceptions) therefore new ClassType[hugenumber] can end up calling ClassType::ClassType() with this=NULL, if the implementation isn't careful to check the return value of operator new *before* beginning to call constructors on the returned chunk of memory. -fcheck-new is GCC's way of telling the compiler that the above scenario could happen (e.g., if you know that your program contains such not-quite-conforming user-defined operator news), and that it needs to generate the code to call constructors on the result of operator new "if and only if the returned pointer isn't NULL". (I'm working on code right now that contains such user-defined operator news. We use -fcheck-new in our Makefiles for GCC, and reluctantly remove -fcheck-new for Clang to avoid the spammy diagnostic. It would be cool if Clang were a drop-in replacement for GCC in this respect.) –Arthur On Tue, Aug 27, 2013 at 5:05 AM, Pavel Labath <[email protected]> wrote: > Hi jordan_rose, > > -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). > > http://llvm-reviews.chandlerc.com/D1528 > > Files: > lib/StaticAnalyzer/Core/ExprEngineCXX.cpp > test/Analysis/NewDelete-path-notes.cpp > test/Analysis/new-with-exceptions.cpp > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
