On Fri, Nov 11, 2016 at 10:45 AM, Mark Wielaard <m...@klomp.org> wrote: > 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.
OK, I suppose that is true. Still seems odd to me, but, whatever. The patch is OK when the copyright assignment is clear. Ian
