On Fri, Nov 11, 2016 at 8:32 AM, Mark Wielaard <m...@klomp.org> wrote: > On Fri, 2016-11-11 at 07:01 -0800, Ian Lance Taylor wrote: > >> Are you completely confident that Rust mangling will never change to >> start requiring more space in the demangled string? If that could >> ever happen, you have chosen an unfortunate API. > > For now, while being based on gnu_v3, yes it will be. And that is really > what the two new interfaces rust_is_mangled () and rust_demangle_sym () > are about. You would only use them if you already know the symbol is > gnu_v3 mangled and might have the "special rust flavor". > > But I expect people normally don't care about the specific mangling > scheme used and would just use rust_demangle () or the more generic > cplus_demangle () which can evolve to support any underlying mangling > scheme. And those really should be used for new code. > > If there are libiberty interface stability issues then we could drop > rust_is_mangled () and rust_demangle_sym () from demangle.h. But I do > think they are useful for how people currently demangle rust symbols (or > if they just need a filter over __cxa_demangle).
If these functions may only work "for now" as you say above, then it seems that they need to be documented as "WARNING: this function may stop working in the future." And if we need to add that warning, and if most people are going to use rust_demangle anyhow, and if new code should rust_demangle anyhow, then I don't see why we should declare these functions in demangle.h. I don't feel especially strongly about this, but it seems a bit weird to add an API that may break irreparably. Ian
