[PATCH] [analyzer] Assume new returns non-null even under -fno-exceptions

Jordan Rose jordan_rose at apple.com
Tue Aug 27 09:16:50 PDT 2013


On Aug 27, 2013, at 9:03 , Arthur O'Dwyer <arthur.j.odwyer at gmail.com> 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




More information about the cfe-commits mailing list