<div dir="ltr">Basically if something can fail, it shouldn't be handled in the constructor, because we have no way to report an error. Instead, we can define a static class member function, say ELFFile::create(StringRef Object), which returns an Error or a new instance of ELFFile.<div><br></div><div>My concern is real. report_fatal_error() calls exit(), so it runs dtors of global objects. If we have a global allocator for ELFFile objects, these ELFFiles' dtors are called on reprot_fatal_error(). Here's a problem: we create an ELFFile from our ObjectFile's ctor, so when ELFFile calls report_fatal_error, our ObjectFile is not fully initialized. That caused ObjectFile's dtor's behavior undefined.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 28, 2016 at 5:53 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27 October 2016 at 18:07, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On second thought, we should never use report_fatal_error in libObject to<br>
> report corrupted input, because it enforces a specific error handling policy<br>
> rather than defer it to an application. Could you return an error instead?<br>
<br>
</span>I like it as an intermediary step.<br>
<br>
It avoids undefined behaviour, which is an improvement.<br>
It is obvious what it does and it let us add a test. With the test<br>
passing we can change the code to return an error.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>