"No way to prevent this" say users of only language where this regularly happens
1–10 of 15 posts
Re: "No way to prevent this" say users of only language where this regularly happens
#2For anyone who doesn't regularly follow The Onion, the verbiage in this post is directly copied from the story The Onion posts after every major mass-shooting in the United States.
An example: https://www.theonion.com/no-way-to-prevent-this-says-only-na...
Re: "No way to prevent this" say users of only language where this regularly happens
#3For anyone who doesn't regularly follow The Onion, the verbiage in this post is directly copied from the story The Onion posts after every major mass-shooting in the United States. An example: https://www.theonion.com/no-way-to-prevent-this-says-only-na...
I knew I recognized it from somewhere, thanks for the context
Re: "No way to prevent this" say users of only language where this regularly happens
#4> users of the only programming language in the world where these vulnerabilities regularly happen once or twice per quarter for the last eight years
I wish!
Re: "No way to prevent this" say users of only language where this regularly happens
#5I'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.
Re: "No way to prevent this" say users of only language where this regularly happens
#6[flagged]
Re: "No way to prevent this" say users of only language where this regularly happens
#7Related (as linked in the article):
CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog()
Re: "No way to prevent this" say users of only language where this regularly happens
#8Very funny!
I just did some coding on C for the first time in years. Now, ok, i'm out of practice, but I'm generally a fairly cautious programmer. I got so many seg faults and weird memory errors in my code. Valgrind found some more that I hadn't spotted.
It's just too easy to screw it up. Much better to use languages that remove entire classes of bug without you having to even think about it.
Re: "No way to prevent this" say users of only language where this regularly happens
#9I'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…
Good point, since of course we’re all using the version of glibc written in the late eighties. (???)
Re: "No way to prevent this" say users of only language where this regularly happens
#10I'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…
Good point, since of course we’re all using the version of glibc written in the late eighties. (???)
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?