[stonogo]

I'm almost positive the project being dunked on here is older than the author. There are plenty of reasons to hate glibc, but nothing productive comes of this kind of noise. It's not like heap overflows are impossible in other languages. Consult https://github.com/rust-lang/rust/issues/80894 or consult your preferred CVE database.

Would love to know what language the author thinks glibc should have been written in in the late eighties.

[ivancho]

I think the dunk is funny, and at the same time recognize that glibc is invaluable. At least here the attackers had to do some memory tricks - in other (apparently safer) languages they just get arbitrary code execution directly implemented in the logger!

[wrs]

Good point, since of course we’re all using the version of glibc written in the late eighties. (???)

[stonogo]

Where in the intervening time would you have recommended a rewrite? Into which language? The other successful libc projects for linux -- bionic and musl -- are also written in C. Which language should they have been written in? Why do you suppose they weren't?

[wrs]

There may be other reasons it’s the way it is, I’m just saying the language choice made 40 years ago is not one of the valid reasons. People do rewrite things, even complicated things, in different languages all the time when there’s sufficient benefit. There have been plenty of other major changes to glibc in that time.

[marcus0x62]

So they should rewrite an implementation of the C standard library in not-C?

[wrs]

It’s a component with very, very high leverage. If you improve glibc then you’ve improved millions of other programs. So I would think all options are on the table.