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

Arthur O'Dwyer arthur.j.odwyer at gmail.com
Tue Aug 27 09:03:37 PDT 2013


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 <labath at google.com> 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>




More information about the cfe-commits mailing list