<br><br><div class="gmail_quote">Le 18 mars 2012 18:52, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Il 18/03/2012 18:26, Matthieu Monrocq ha scritto:<br>
><br>
><br>
> Le 18 mars 2012 12:51, Abramo Bagnara <<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a><br>
> <mailto:<a href="mailto:abramo.bagnara@gmail.com">abramo.bagnara@gmail.com</a>>> a écrit :<br>
><br>
>     In <a href="http://llvm.org/docs/CodingStandards.html#ci_rtti_exceptions" target="_blank">http://llvm.org/docs/CodingStandards.html#ci_rtti_exceptions</a> I read<br>
>     that exceptions are not used by design in clang code base.<br>
><br>
>     Despite this in source there are a lot of unguarded call to new<br>
>     operator, does this means that when memory is lacking the compiler<br>
>     executable is meant to fail in arbitrary way?<br>
><br>
>     Here below you can see a typescript showing a simulated example:<br>
><br>
>     $ ( ulimit -v 66000 ; clang -cc1 -ast-dump bzip2.c )<br>
>     0  _clang    0x000000000247ad66<br>
>     1  _clang    0x000000000247ab62<br>
>     2  libc.so.6 0x00007f1c0974e420<br>
>     3  _clang    0x0000000000b9e33c<br>
>     4  _clang    0x00000000019cb626<br>
>     clang::SrcMgr::ContentCache::getBuffer(clang::DiagnosticsEngine&,<br>
>     clang::SourceManager const&, clang::SourceLocation, bool*) const + 398<br>
>     5  _clang    0x000000000198d748<br>
>     6  _clang    0x000000000198bc01<br>
>     clang::Preprocessor::EnterSourceFile(clang::FileID,<br>
>     clang::DirectoryLookup const*, clang::SourceLocation) + 291<br>
>     7  _clang    0x00000000019a4e42<br>
>     clang::Preprocessor::EnterMainSourceFile() + 166<br>
>     8  _clang    0x0000000000f14da0 clang::ParseAST(clang::Sema&, bool)<br>
>     + 271<br>
>     9  _clang    0x0000000000bf3abd<br>
>     clang::ASTFrontendAction::ExecuteAction() + 265<br>
>     10 _clang    0x0000000000bf3713 clang::FrontendAction::Execute() + 245<br>
>     11 _clang    0x0000000000bcd9ff<br>
>     clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 673<br>
>     12 _clang    0x0000000000ba17c8<br>
>     clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 957<br>
>     13 _clang    0x0000000000b9074c cc1_main(char const**, char const**,<br>
>     char const*, void*) + 999<br>
>     14 _clang    0x0000000000b9cd8b main + 496<br>
>     15 libc.so.6 0x00007f1c0973930d __libc_start_main + 237<br>
>     16 _clang    0x0000000000b8f9c9<br>
>     Stack dump:<br>
>     0.      Program arguments: clang -cc1 -ast-dump bzip2.c<br>
>     1.      <eof> parser at end of file<br>
><br>
> A quick grep of the LLVM and Clang source code shows that the "operator<br>
> new" is often overloaded for the base types of the hierarchies, so most<br>
> of the new calls in the source are not calls to the global "operator<br>
> new" provided by the compiler implementation but instead redirect to<br>
> specialized versions. For example, look into ASTContext.h.<br>
><br>
> I recall a comment of Doug saying that the custom "operator new" never<br>
> return 0, so checking is not necessary. It seems that most calls end up<br>
> into llvm/Support/Allocator.h and there only seem to be some asserts there.<br>
<br>
I've personally verified (in another debug session) that llvm:DenseMap<br>
uses global operator new and it is not the only.<br>
<br>
Furtherly clang uses std::string, std::vector, std::set, etc.<br>
<br>
Do you think that the intention is to never use global operator new?<br>
<br></blockquote><div> </div></div>No, I don't, though I would have expected the usage to be less pervasive :)<br><br>I suppose your earlier diagnostic was right then, and that an out of memory condition is just supposed to fail badly. It is a rare condition anyway nowadays and there is not much one can do apart from stopping.<br>
<br>-- Matthieu<br>