[llvm-dev] PVS-Studio analysis of LLVM code

Yury Mikhaylov via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 3 12:23:47 PDT 2016

> LLVM shouldn't replace new with new(std::nothrow), it should just abort.
Does it? When we were evaluating embedding LLVM a few years back, that was
one of the major pain points for us. Something goes wrong and LLVM/Clang
calls abort, crashing the whole program. Library shouldn't make these type
of decisions lightly: return an error, throw an exception, fire up a smoke
signal - whatever - but there's just not enough context to decide right at
that level.

> There's effectively zero chance the codebase will ever be able to recover
> from OOMing, and with modern OSes, you're almost never going to actually
> see a malloc failure until it's way too late, anyways.
IMO the best way is to allow user to specify their own allocation strategy
with default fallback to std::new: JITs have bursts of activity between
longer quiet periods and may want to defer memory cleanup until later; IDE
with code completion may want to keep memory consumption in check and
choose to disable whole feature, rather than impede other processes; and so

- Yury
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161103/f01be6c1/attachment.html>

More information about the llvm-dev mailing list