On Fri, 2016-11-11 at 09:11 -0800, Ian Lance Taylor wrote: > 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.
The API won't break irreparably. If rust would adopt a different mangling scheme in the future then rust_is_mangled () would simply return false and rust_demangle_sym () is documented to only work on symbols that (after being gnu_v3 demangled) return true when given to rust_is_mangled (). So they keep working, but might just return false if some future rust demangling scheme is completely different. It would just be like if any other language adopted a different/new mangling scheme. Then you simply wouldn't be able to demangle the symbol. For reference this is how they are documented: /* Returns non-zero iff MANGLED is a rust mangled symbol. MANGLED must already have been demangled through cplus_demangle_v3. If this function returns non-zero then MANGLED can be demangled (in-place) using RUST_DEMANGLE_SYM. */ extern int rust_is_mangled (const char *mangled); /* Demangles SYM (in-place) if RUST_IS_MANGLED returned non-zero for SYM. If RUST_IS_MANGLED returned zero for SYM then RUST_DEMANGLE_SYM might replace characters that cannot be demangled with '?' and might truncate SYM. After calling RUST_DEMANGLE_SYM SYM might be shorter, but never larger. */ extern void rust_demangle_sym (char *sym);
