[PATCH] D13989: This removes the eating of the error in Archive::Child::getSize() when the charactersin the size field in the archive header for the member is not a number.

[Kevin Enderby via llvm-commits]

> On Nov 4, 2015, at 12:49 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
>>> A broken .o/.a file is a really rare occurrence.
>> 
>> Not for me.  As a developer of object file tools I often find myself trying to figure out why a binary is broken.  Having tools that simply give up and not print any data I personally don’t find useful.
> 
> Or me, but I don't think we are common enough that we should design for it :-)

Again I respect your opinion.  But the whole reason I wrote darwin’s otool(1) many years ago was to be able to do my job and develop tools that wrote binaries.  Often during development the binaries were broken and I needed a tool to find out what was wrong.  I think it is odd that for llvm tools, which are tools for compiler developers, we are not “common enough” to design tools we need.  That is tools being able to work on broken binaries and tell us as much as it can.

> 
> When starting the new lld I was running gdb on dynamic linkers and
> reading kernel code to figure out why they would reject the lld
> produced files. Given how often new linkers get written, that is
> pretty reasonable.
> 
>> Often times it is a disk has filled up and a file got truncated in a build.
> 
> That is a bug in the generator.

It is usually a problem with a copy like operation of some tool copying around a root and not a bug in the generator of the binary which I have found to be the normal cases when this happens.

> It should be doing a rename once the
> entire file has been fully written to disk. If you ever see a llvm
> tools that is not doing that please report a bug.
> 
>>> Given that it is a really uncommon case, I think we should make the
>>> handling in tools as simple as possible: if at all possible, just
>>> exit(1).
>> 
>> Again I respect your opinion.  But I disagree. Most of my time is spent looking at things that are broken.  Things that work and are correct I spend very little time with.
> 
> You can print a good error message and I encourage you too, but if so:
> 
> * The code should still look something like
> 
> std::string niceAndDescriptiveError = compute it in some way...
> fail(niceAndDescriptiveError); // this will not return.
> 
> * If we need a nice error, it is a feature. If it is a feature we
> should test for it.

OK, I guess I can live with at least being allowed to produce a good error message.  I would prefer to for the tool to continue on if possible and on to other files but if llvm tools must exit upon the first error I can adapt to that.

> 
> Cheers,
> Rafael