[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