Hacker News Reader

Comment by Someone1234 | Hacker News Reader

Is there a good reason why a binary compatible glibc couldn't be re-written in a better language? People are always going to be using C/C++ and there is little that can be done about that exposure, but at least the libraries they rely upon could be better engineered to have certain assurances about safety.

View on HN

You'd lose most of the safety. E.g. a lot of the value of Rust comes from ownership tracking, but you can't track ownership across a C-ABI boundary because the information simply isn't there. And I'm not sure assurances in libraries used by unsafe languages are really that valuable - it'd be like locking your back door and leaving your front door open. Better to make a clean break.

Most of the bad stuff in glibc is due to bad API's, not to bad programming languages. (E.g., non-reentrant functions with global state, functions that deliberately crash on incorrect input, poor separation between standard library functions and non-standard but commonly accepted ones, poor separation between stuff that's needed for C and stuff that wraps kernel/syscall functionality, etc.)

Parts of it probably should be replaced with safer implementations, but as long as you're going for 100% compatibility you're still putting lipstick on a pig.

I don't think there's a reason why it couldn't happen at least in parts – it sounds like that's Mozilla's plan for migrating parts of Gecko – but I suspect you'd hit an 80/20 rule pretty hard where many programs could use your alternate libc but a fair amount of code would have different results due to arcane details for things like threading, signal handling, etc. and it would be quite time-consuming to hit complete compatibility.

I don't think it would be worthwhile to rewrite all of glibc, at least not initially. We should focus first on libraries that parse attacker-controlled input, such as glibc's DNS resolver, image libraries, font libraries, etc. Most of glibc does not parse attacker-controlled input and is probably already safe.

Microsoft re-wrote their C runtime library in C++, taking advantage of the language features for writing safer code.

https://blogs.msdn.microsoft.com/vcblog/2014/06/10/the-great...

There could be bad habits built into glibc that everyone has just learned to live with, that Rust explicitly forbids, or makes difficult to reimplement, such that doing so would reintroduce all of the same problems as before.

Reply on news.ycombinator.com