5 ms·

LLVMs libcxxabi has a demangler which doesn't have the worst looking code in the world[0], has no external dependencies (outside of the C++ standard library),

• simcop2387 10y ago
  The best way is to make sure it's correct to every test case you can find. I.e. include the test s you point to there along with the tests from libiberty etc. That'll at least let you say that's it's as provably correct as the others. The next advantage is going to be that Rust helps prevent certain classes of bugs (in this case memory issues) as long as you're not doing unsafe{} things. And while that rests on Rust's ability to prove that it's a step up from not having that. The handwritten parser doesn't mean much in the advent of testing against a wide array of inputs, if it was parsing incorrectly then it's not going to pass the tests. Sure there might be an edge case where it just recurses but that's also the case of libcxxabi and the others. The code being longer also means basically nothing. It just means that either the code is more verbose or could be shortened somehow it says nothing about it's correctness or viability.
• roca 10y ago
  It's true that one can't be sure the Rust version is "any more correct and won't eat all your memory". However, an even more important question is how many exploitable bugs remain in the LLVM library vs the Rust library. The data suggests that the answer for Rust is zero but the answer for LLVM is greater than zero.
  • kbenson 10y ago
    > The data suggests that the answer for Rust is zero Let's not go overboard. Claiming the number of bugs is zero in any non-trivial piece of software is generally a losing proposition, no matter the language. That said, I think I know what you're trying to express, and I would say it like this: The number of bugs in a program written in Rust compared to C or C++ should be statistically less, all other things being equal. Certain classes of bugs are impossible with Rust at best, and easier to locate or isolate at worst (assuming you haven't wrapped the entire program in one giant unsafe block).
    • roca 10y ago
      For bugs in general sure, but I specifically said "exploitable bugs" which is a different story. I don't think it's going too far to say that the probability of a Rust compiler bug, or a bug in unsafe Rust library code, leading to an exploitable issue in the Rust demangler, is low.
      • kbenson 10y ago
        The implication being that it's impossible to write exploitable code without using unsafe? First, that's not a claim I've heard made, second, I'm far too conservative (having been around long enough) to believe Rust code in general can't be exploited, given enough time and effort by smart people, even if that's the current belief. Whole new classes of exploits occasionally pop up, and you can't reliably protect from that which you know nothing about.
  • pcwalton 10y ago
    > The data suggests that the answer for Rust is zero but the answer for LLVM is greater than zero. Well, it's been fuzzed, so there's a pretty decent chance that the LLVM code has zero exploitable flaws. Also, the C++ demangler isn't as security-sensitive as many other more important projects. That said, as a general rule raw C-style string parsing, which that C++ code is an example of, is asking for trouble. It's painful to write, painful to maintain, painful to debug, and, when it fails, fails in the worst possible way. In my opinion there's little benefit to using C++ for these workloads.
• Joky 10y ago
  I don't know if does not have the worst looking code in the world, but in my opinion it is far far worst that what I can bear with. It should die, the sooner the better, and we'll be happy for anyone to provide a replacement. If this wasn't written in Rust I'd adopt it in LLVM!
  • kbenson 10y ago
    That brings up an interesting question, since it sounds like you might have some inside information: Is LLVM amenable to using a library for this functionality, or is it considered something which must be maintained in-project? I ask because at the point that something is compiled to a library, the source implementation shouldn't really matter (ignoring silly things like embedding a VM), so at that point this being implemented in Rust shouldn't matter too much (beyond it possibly being less familiar to the LLVM devs). Not that I'm actually advocating for that at this point. This is a new library, and as stated in the blog still has some differences in output compared to other similar libraries.
    • Joky 10y ago
      You have to understand that one of LLVM goal is to provide a full toolchain, through reusable library components. So we're seeking to provide our own solution for this, and we're actually providing this feature as a library for a long time. If you're on macOS, it is the default libc++-abi and you can have it available on any macOS system: $ nm /usr/lib/libc++abi.dylib | grep cxa_demangle 00000000000018e0 T ___cxa_demangle Which means you can compile the following c++ file with clang++ and gets demangling from the system: #include <iostream> extern "C" char *__cxa_demangle(const char *mangled_name, char *buf, size_t *n, int *status); int main() { std::cout << "Demangled: " << __cxa_demangle("_Z17GetExecutablePathPKcb", nullptr, nullptr, nullptr) << "\n"; } We need a great demangler in LLVM because we're using it in the LLDB debugger for instance. The LLVM one is quite slow actually, if anyone is interested in writing a (clean) very performant C++ one within LLVM, I'm volunteering to help the review and integration :) (edit: formatting)
      • kbenson 10y ago