[patch] Fix use after free in BitcodeReader.cpp error path

[Tobias Grosser]

On 10/30/2013 07:24 PM, Rafael Espíndola wrote:
>>> do we interface
>>> "rich" non fatal errors with APIs that use error_code? Do we extend
>>> error code to carry a std::string too?
>>
>>
>> $ grep error_code lib/Bitcode/* -R
>> $
>>
>> This gives zero results. Which API are you talking about? Do those API's
>> really need std::string? Or are you saying they are forwarding the
>> result of the Bitcode reader?
>
> I found this when I started to implement a ObjectFile interface for
> bitcode files. I want that so that llvm-nm and llvm-ar (for now) can
> transparently use bitcode files. The interface used by ObjectFile is
> based on error_code.

Just out of interest. Are you planning to make the use of bitcode files 
supported for a wider audience? The problem I see here is that there is 
no good way for the tools to check if a certain bitcode file can be 
correctly read. At the moment, we are sometimes crashing, but e.g. the 
bug that I fixed caused invalid bitcode to be read. So bitcode files are 
only known to be really compatible for tools that use the very same 
version of LLVM (we try to maintain the ability to read older bitcode 
files, but this is not very well tested).  If we want to change this, we 
probably need some kind of version marker.

>> Another option would be to just drop the AttributeKind id, in case Nick is
>> OK with this.
>
> Yes, that would also work.

Given the choice between this and the ability of gracefully fail if 
reading bitcode files, I very much prefer this.

I copied Nick to get his opinion.

Cheers,
Tobias