[PATCH] D123420: [demangler] Rust demangler buffer reuse
Nathan Sidwell via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Apr 11 04:56:19 PDT 2022
urnathan added a comment.
In D123420#3440296 <https://reviews.llvm.org/D123420#3440296>, @tmiasko wrote:
> The API thus far was intended to match that of `__cxa_demangle`, where the caller retains the ownership of the provided buffer when demangling fails. This is no longer the case in the new implementation. I would rather avoid diverging from `__cxa_demangle` in such a subtle way.
Ah, it took me a while to figure out where that's happening, I see it now. Awkward. I suppose the rust demangler could always return the new buffer (and free any incoming buffer) in the success case? Something like `if (Buf) std::free(Buf);` instead of that memcpy/free dance?
> The Itanium demangler gets away with the direct use of the buffer because it separates fallible parsing from infallible printing.
Any thoughts about doing similar in the Rust demangler -- passing an output buffer reference around or something?
>> the length of the incoming buffer will have come from a previous call, which was the length of the demangled string
>
> I think this is a bug in the implementation. The *N should have been updated to reflect allocated memory size. From Demangler API in Itanium C++ ABI:
>
>> In either case, the new buffer size will be stored in *n.
Indeed, that's the direction I'm trying to go in :)
FWIW, this is part of a series trying to make buffer ownership transfer clearer (and other issues)
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D123420/new/
https://reviews.llvm.org/D123420
More information about the llvm-commits
mailing list