In the eternal quest to rewrite everything in Rust, even the C standard library isn’t safe from carcinisation.
  • snaggen@programming.devOP
    41·
    1 year ago

    As I still run in to glibc version issues a little now and then (admittedly not very often, thankss to containers), I hope to see rust getting rid of libc one day. But I don’t expect that in the near future, because as the author mentions, libc is very mature, so replacing it must be done with a lot of caution. But this really looks like a step in the right direction.

    • BB_C@programming.dev
      7·
      1 year ago

      Funny you should mention that. Recently, glibc 2.38 was released with broken performance in its allocator API. Hell, one of the developers tried to argue the regression is good to force people to stop using the regressed API unnecessarily (the argument didn’t go far, regressions got fixed).

      Reports in the wild:
      https://github.com/mpv-player/mpv/issues/12076
      https://bugs.archlinux.org/task/79300

      Links to the libc-alpha relevant threads can be found there.

      Speaking of libc allocators, musl’s allocator is also shit. That’s why some Rust projects use another global allocator in their musl builds. Some of them probably haven’t noticed yet that those builds are not static anymore because of that 😉 .

      • Nereuxofficial@programming.dev
        1·
        1 year ago

        Hmm now it would be interesting how eyra fares for allocating. And also why does musl not implement a faster allocator? I get that it should be backwards compatible but the gap to glibc seems to be really large.