[PATCH] D91693: [Support] Add reserve() method to the raw_ostream.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 24 13:18:18 PST 2020


dblaikie added a comment.

In D91693#2410578 <https://reviews.llvm.org/D91693#2410578>, @labath wrote:

> In D91693#2407967 <https://reviews.llvm.org/D91693#2407967>, @avl wrote:
>
>>> Yeah, I suppose that's reasonable. Though, if the scope of this is small (e.g.: it only needs to write to files _or_ memory buffers, and it's not going go have a lot of callers/large surface area), I would not completely dismiss some custom solution either...
>>
>> This work is done exactly because of scope for custom solution become wider. There is a D88827 <https://reviews.llvm.org/D88827> review which tries to move core implementation of llvm-objcopy into the Object library. So there is a request to avoid using custom solution in favor of more standard one. That is why I am trying to replace custom llvm-objcopy solution(D91028 <https://reviews.llvm.org/D91028>).
>
> Ok, fair enough.
>
>>> I don't think that would be *un*reasonable, but I'd wait until a use case for it shows up.
>>
>> There is such a use case in D91028 <https://reviews.llvm.org/D91028>
>>
>>   SmallVector<char, 0> Buffer;
>>   raw_svector_ostream MemStream(Buffer);
>>   
>>   if (Error E = executeObjcopyOnBinary(Config, **ObjOrErr, MemStream))
>>     return E;
>
> Seems reasonable, then. I would like to get a second opinion though..

@jhenderson mind chiming in here? If you and @labath find agreement with the direction, that seems good to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91693/new/

https://reviews.llvm.org/D91693



More information about the llvm-commits mailing list