[cfe-dev] -fcheck-new not supported by LLVM/clang

[Matthieu Monrocq]

On Tue, Nov 6, 2012 at 10:43 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Tue, Nov 6, 2012 at 1:22 PM, Beinan Li <li.beinan at gmail.com> wrote:
> > Hello LLVM/Clang,
> >
> > With Xcode4.5, llvm/clang:
> > Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM
> 3.1svn)
> > Target: x86_64-apple-darwin12.2.0
> > Thread model: posix
> >
> > we use -fcheck-new in our compiler settings which has been triggering
> this
> > clang warning:
> >
> >> clang: warning: argument unused during compilation: '-fcheck-new'
> >
> >
> > We wonder if this gcc setting is not supported by clang.
>
> It is not supported; "argument unused during compilation" is the
> generic "I don't know what you're asking for, so I'm ignoring it":
> warning.
>
> -Eli
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

I would note that on Linux, with overcommit, this is probably useless
anyway.

Unless you grow out of address space, which is hard on 64 bits systems
(2^47 bytes of available address space) which would lead the kernel not to
allocate memory, the kernel will hand over a pointer to a memory page
whenever `malloc` requires it, even though the page itself might be much
smaller than the requested block, and the memory in the block will be
effectively allocated *when written to* (or read from... I guess).

As such, `malloc` should never return a null pointer, making
`std::bad_alloc` a somewhat mystic creature (even with exceptions enabled).
And in the worst case, the constructor call (after `new` returned but
before your applicative code is handed over the pointer) will write to a
memory zone for which no page can be allocated and your program will crash
(*).

So, at least on Linux, I would see `-fcheck-new` as a dubious flag.

-- Matthieu

(*) Note: there is a oom killer process that is supposed to kill random
programs on the machine to free up memory when it is exhausted...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121107/d74f9d0d/attachment.html>