On Aug 27, 2013, at 9:03 , Arthur O'Dwyer <[email protected]> wrote:
> 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.) > Thanks for catching the comment thing, Arthur. I think it's okay for this to go in unrelated to -fcheck-new, since it's an analyzer option and the analyzer is most useful when checking plausible paths that could nonetheless lead to errors. Pavel, good catch on the mistaken logic here. I agree with Anna, this looks good. Jordan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
