9 ms·

I don't understand why this keeps getting passed around. Buffer overflows in the hash reference implementations have zero relevance on the algorithm's hashing

• jrockway 18y ago
  The article does not use the buffer overflows to conclude anything about the algorithm -- it concludes that writing software that manages memory correctly is very difficult. This is why you should all stop using C, and people should stop telling other people to use C. (Anything I would use C for, I now use Haskell for. Everything runs as fast, and the language and libraries are much better.)
  • tptacek 18y ago
    That's nice. Almost nobody is using C anymore --- especially for the web apps we talk about here. But everyone drops to native code for encoding/decoding; in Python, Perl, or Ruby, you're calling OpenSSL to get your crypto primitives, an OpenSSL is gnarly C code.
    • neilc 18y ago
      No one is using C anymore, except for trivial things like kernels, database systems, and VMs.
      • jrockway 18y ago
        Kernels are trivial (straightforward is a better word) and are very close to the hardware, so C works pretty well for them. If you started a new OS kernel today, though, you wouldn't have to pick C. The other things are just going on momentum. C is not a good choice for those applications. (For example, look at SBCL and GHC. Two of the fastest language runtimes, and both are self-hosting. Yeah, you need a little bit of C to interface with the underlying OS, but the critical parts are not C.) Anyway, nice attempt at snark. It earned you an upmod.
        • likpok 18y ago
          The bigger issue with kernels is that they are, as you say, close to the hardware. That makes them harder to do in higher level languages (you need something to run on...). However, it is possible to do, for example Singularity. Personally, I think that the "kernel" will begin to be a smaller and smaller part of the OS. More like L4 et al, as the performance costs become smaller (L4 is already pretty good). Eventually, C might become the old assembly; you need a small amount of it to get started, but once you've boostrapped, you can live in higher-level code.
          • tptacek 18y ago
            I don't think proximity to the hardware is a big issue (we do a lot of hardware work --- at the interrupt-handler, polling-MSRs, hard-timer level --- and we take pains to stay in Ruby, an incredibly slow language. I think the issue is first performance (you can't context switch fast enough in a high-level language, and more importantly the concept of a context switch in most OSs is kind of tuned to the C language), and the second is universality; you want the lowest common denominator in the kernel.
      • tptacek 18y ago
        RDBMS's seem like the next likely C stronghold to fall; they're I/O bound and feature-laden.
        • timf 18y ago
          Isn't there a lot of pointer arithmetic in RDBMS land?
          • jrockway 18y ago
            Well, it's written in C. That's what everything written in C does.
            • timf 18y ago
              My point was that database performance goes far beyond "waiting for the disk." The data is laid out in specific ways with specific widths, there are decades of implementation experience behind making queries and inserts fast because of this. Among many other things, controlling which part of the disk based data to mmap in. These are things that a higher level language's runtime can't just optimize for you.
              • tptacek 18y ago
                What part of laying things out in specific widths prohibits an implementation in a high level language? From 2001-2005, at Arbor Networks, I worked on a codebase that basically had to bucket the entire Internet, as seen from (say) the core routers at British Telecom, on varying timescales. Obviously, we wrote it in C. It was not optimal. What's worse, changing it was a huge nightmare. Most of the performance improvements we came up with (at least in my first year) were design issues (like messing with precision, storing runs of zeroes, things like that). Most of the bugs we has were textbook C issues, like failing to address shared memory properly. I'm totally not sold that high speed disk I/O demands C.
                • timf 18y ago
      • jamii 18y ago
        Statistically speaking, noone is writing kernels, database systems and VMs. You're a statistical anomaly.
    • jrockway 18y ago
      Most of the Perl crypto libraries use Pari or GMP, actually. Your point still holds, however. You will notice, though, that the Haskell crypto libraries are generally "pure Haskell", since there is not much of a speed hit for not using C. This is the Future.