[patch] Don't own the buffer in object::Binary

[Rafael Espíndola]

An updated version is attached.

The main difference is that now Object keeps a reference both to the
data and to the name instead of copying the name to a std::string. I
also changed Archive to provide MemoryBufferRef to access its members
instead of MemoryBuffers.

I think this is in good enough shape for a code review now :-)


On 1 August 2014 16:32, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> There were quiet a few requests for not owning the buffer in
> object::Binary, this an attempt to make that happen (and make it
> obvious in the API).
>
> The patch is intentionally focused on lib/Object. If some other
> structure had a std::unique_ptr<Binary>, now it also has a
> std::unique_ptr<MemoryBuffer>.
>
> The main things It would be nice to have some feedback on:
>
> * MemoryBufferRef. Should this have another name? Should it implement
> more of the MemoryBuffer API instead?
>
> * OwningBinary: We need something like this for the convenience
> methods that construct an ObjectFile from a file name.
>
> * What should we do about the C API? Should it start wrapping
> OwningBinary instead of Binary to keep the existing semantics? Should
> we put a big warning in the 3.6 release and change it (I don't expect
> too many users at this point)?
>
> * There is still a fixme about removing getMemoryBuffer from Archive.
> I should have an updated patch with that early next weak, but I don't
> expect it to change anything in a fundamental way.
>
> I am still running the tests with Valgrind, but we can probably start
> the review in parallel.
>
> Cheers,
> Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 66255 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140806/ebe56fb3/attachment.bin>