I think a lot of the absolutists around memory safety are just using it as a bludgeon to evangelize their preferred programming language. Otherwise, the position of "memory safety is the most important thing, but we should ignore other languages that provide stronger guarantees" is absurd.
> Take Herb Sutter for example, who argues that "memory safety" as defined in this article is an extreme goal and we should instead focus on a more achievable 95% safety instead to spend the remaining effort on other types of safety.
I don't really see how that's a) a scepticism of memory safety or b) how it's not seen as a reasonable position. Just because someone doesn't think X is the most important thing ever doesn't mean they are skeptical of it, but rather that the person holding the 100% viewpoint is probably the one with the extreme position.
[A] program execution is memory safe so long as a particular list of bad things, called memory-access errors, never occur
"95% memory safety" is not a meaningful concept under this definition! That's very much skepticism of memory safety as defined in this article, to highlight the key phrase in the comment you're quoting.
It's also not a meaningful concept within the C++ language standard written by the committee Herb Sutter chairs. Memory unsafety is undefined behavior (UB). C++ code containing UB has no defined semantics and is inherently incorrect, whether that's 1 violation or 1000.
Now, we can certainly discuss the practical ramifications of 95% vs 100%, but even here Herb's arguments have fallen notoriously flat. I'll link Sean Baxter's piece on why Herb's actual proposals fail to achieve even these more modest goals as an entry point [0]. No need to rehash the volumes of digital ink already spilled on this subject in this particular comment thread.
Skepticism of an absolutist binary take on memory safety is not the same as skepticism of memory safety in general and it's important to distinguish the two.
It's like saying that people skeptical of formal verification are actually skeptical of eliminating bugs. Most people are not skeptical of eliminating bugs, but they might be skeptical of extreme approaches to do so.
As I explained in a sibling comment, memory safety violations aren't comparable to logic bugs. Avoiding them isn't an absolutist take, it's just a basic requirement in common programming languages like C and C++. That's not debatable, it's written right into the language standards, core guidelines, and increasingly government standards too.
If you think that's impossibly difficult, you're starting to understand the basic problem. We already know from other languages that memory safety is possible. I've already linked one proposal to retrofit similar safety onto C++. The author of Fil-C is elsewhere in these comments arguing for another way.
Everything you say about memory safety issues applies to logic bugs too. And likewise in reverse - you can have a memory safety issue that doesn't result in a vulnerability or crash. So I don't buy it that memory safety is so different from other types of bugs that it should be considered a binary issue and not on a spectrum like everything else!
> Everything you say about memory safety issues applies to logic bugs too.
It doesn't, because logic bugs generally have, or can be made to have limited scope.
> And likewise in reverse - you can have a memory safety issue that doesn't result in a vulnerability or crash.
No you can't, not in standard C. Any case of memory unsafety is undefined behaviour, therefore a conforming implementation may implement it as a vulnerability and/or crash. (You can have a memory safety issue that happens to not result in a vulnerability or crash in the current version of gcc/clang, but that's a lot less reassuring)
This whole memory-bugs-are-magical thinking just comes from the Rust community and is not an axiomatic truth.
It’s also trivial to discount, since the classical evaluation of bugs is based on actual impact, not some nebulous notions of scope or what-may-happen.
In practice, the program will crash most of the time. Maybe it will corrupt or erase some files. Maybe it will crash the Windows kernel and cause 10 billion in damages; just like a Rust panic would, by the way.
We simply don't treat "gcc segfaults on my example.c" file the same way as "libssl has an exploitable buffer overflow". That's a synopsis of the nuance.
Materials to be consumed by engineers are often unsafe when misused. Not just programs like toolchains with undefined behaviors, but in general. Steel beams buckle of overloaded. Transistors overhead and explode outside of their SOA (safe operating area).
When engineers make something for the public, their job is to combine the unsafe bits, but make something which is safe, even against casual misuse.
When engineers make something for other engineers, that is less so; engineers are expected to read the data sheet.
even if you know what the data sheet says, it's easier said than done, especially when the tool gives you basically no help. you are just praying people will magically just git gud.
Corporations are not legally humans and nobody who isn't either misinformed or purposely strawmanning considers a corporation to be a human. Legal personhood just means that a corporation can be a legal actor and possess certain rights and responsibilities. Perhaps they should have called it persona ficta as they did 800 years ago, but the concept is useful and is not, like others in this thread have suggested, something that greedy corporations use to legally bludgeon the proletariat with.
No, the problem is the extent to which private parties can use the power of law to legally restrict your usage of property you own. And that's the reason it's a right.
If you don't like the restrictions a product has you can simply not purchase the product, no "right" has been infringed.
The issue is societal lockin - aka network effects. People can't afford to "not buy one" because then they are "the one without".
Banking apps, delivery apps, public transport apps, utilities apps, insurance - so many services have been captured by the big two phone oligopoly that modern life revolves around your phone. The assumption is that you will have one.
Sure, you could decide not to, but you are instantly a societal pariah as every business finds it s so much harder to deal with you - and you don't have enough time in the day to deal with the secondary processes these businesses employ, for every aspect of your life.
Maybe it's country specific - here in Canada I don't feel like I need a smart phone for anything crucial. There is a trend where people including zoomers such as myself switch to dumb phones for a "digital detox". So it seems perfectly feasible to do so.
I was called a luddite for not wanting to follow the "official" schoool Whatsapp group. Online banking is practicably unusable without the bank's own 2FA app.
Many things can still be done in a web browser, but the rest of society is going the smartphone route and it's increasingly difficult to avoid it.
Any non-digital options are aimed at elderly and handicapped individuals; not people who don't want smartphones.
Some people can do it. I'd also ditch my smartphone if I was living in the woods, or had a personal assistant handling my daily needs, or lived in an Amish community etc.
But I don't see the vast majority of people to be able to ditch their smartphone, that's just not a reasonable proposition.
A few people can live with just phone calls, but a sizeable majority use some additional apps for texting. Dumb phones won't work here.
1. Many people use a virtual text number, like google voice
2. Maybe even more folks use one or more app based texting services. I bet many users here have several on their phone:
Signal
What's app
telegram
There are probably 50 texting type apps in this category
These are dangerous attack vectors for people trying to remotely control your phone, but also important to talk to your friends.
I think we need a solution for these types of apps for a popular usable solution. I don't know how to solve the safety issue when running these apps, and I can't just "forward" text messages to my dumb phone.
But 30 years ago there were also no government services or major companies who require you to interact with them using an app on a major smartphone platform.
Nothing has changed, there are no government services or major companies who require you to interact with them using an app on a major smartphone platform.
There are many that do require SMS or a phone number of some sort at this point.
We are mostly saved by the part of the 70+ crowd who is completely computer illiterate and own significant investment resources. But that will only last 10-20 more years.
How does (great) past suffering justify (mild) modern suffering?
And my forefathers probably fought in wars against your forefathers. The world would have probably been better off, if they all had just stayed home. Nothing glorious about that.
Yeah I don't think you ever could just call MyComponent(props) directly if the component used hooks. If it was hookless (what a concept...) it wouldn't matter.
It's always seemed obvious to me that it would be better to make C safer than it would be to rewrite the billions of lines of C that run all our digital infrastructure. Of course that will get pushback from people who care more about rewriting it in a specific language, but pragmatically it's the obvious solution. Nice to see stuff like Fil-C proving it's possible, and if the performance gap can get within 10% (which seems very possible) it would be a no-brainer.
It depends how much the C software is "done" vs being updated and extended. Some legacy projects need a rewrite/rearchitecting anyway (even well-written battle-tested code may stop meeting requirements simply due to the world changing around it).
It also doesn't have to be a complete all-at-once rewrite. Plain C can easily co-exist with other languages, and you can gradually replace it by only writing new code in another language.
The concept of a school wouldn't be illegal. The people running the school would be committing crimes or at least be in some level of legal trouble with the city council, state or federal law. They could either be fined or go to prison, or they could get the relevant paperwork sorted out.
Yes it is, you explicitly said it would be illegal if you didn't get permission from the government. What you meant to say was that "The concept of a government-approved school wouldn't be illegal." which is very different from the concept of any school being legal, and also redundant because by definition a government-approved school is a legal school, since governments hold a monopoly on the legal system.
reply