[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