5 ms·

Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64

Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language? Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-safe, where does it begin to break down?

afdbcreid 3y ago
I don't think you can do that without massive changes to existing codebases, at which point why not just use Rust? There might be a better path for memory-safe language interoperable with C++ (Carbon?) but this will require significant effort.
ahmedfromtunis 3y ago
I think this is, realistically, the easiest way to solve the problem. That, or a totally different language that is (somehow) a drop-in replacement for c/c++. I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces. A year of concentrated efforts might be sufficient to rid us with this problem once and for all.
matthewaveryusa 3y ago
I think you would need to go the go/rust route of explicitly calling out unsafe code blocks.
ruszki 3y ago
Why you need fixed-size strings? Btw I don’t know how this works in most languages, but circular references can be still a problem even with these restrictions. (If I remember well dangling references can be more or less handled, but correct me if I’m wrong. I remember that JavaScript definitely had problem with those)
- gosub100 3y ago
  I was only tossing it out there as a token example. You can manipulate the heap in a minor way if you continually request and free memory in irregular ways (called mem fragmentation). Fixing the size (might) be one step towards hardening the system against OOM attacks. overall, I'm just wondering why we can't make C++ safe by starting at the lowest layers, mem-proofing them, and working up from there (and limiting/discarding some features along the way if necessary).
weinzierl 3y ago
We do, one approach is MISRA and it is ubiquitous in automotive.
UncleMeat 3y ago
"Ban a ton of widely used C++ features" creates a problem that is smaller than but still comparable to "rewrite it in rust." You also still have some features of modern defensive C++ that can still be abused and cannot be removed from the language or made safe without something resembling the Rust borrow checker. Getting these features in the C++ language itself will be absolutely impossible, both because of massive performance implications and well as nightmarishly large ABI breaks on everything. There are various efforts to do what you are describing. I think that they are often a good idea, but they absolutely will not solve the problem conclusively.

afdbcreid 3y ago

I don't think you can do that without massive changes to existing codebases, at which point why not just use Rust? There might be a better path for memory-safe language interoperable with C++ (Carbon?) but this will require significant effort.

ahmedfromtunis 3y ago

I think this is, realistically, the easiest way to solve the problem. That, or a totally different language that is (somehow) a drop-in replacement for c/c++. I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces. A year of concentrated efforts might be sufficient to rid us with this problem once and for all.

matthewaveryusa 3y ago

I think you would need to go the go/rust route of explicitly calling out unsafe code blocks.

ruszki 3y ago

Why you need fixed-size strings? Btw I don’t know how this works in most languages, but circular references can be still a problem even with these restrictions. (If I remember well dangling references can be more or less handled, but correct me if I’m wrong. I remember that JavaScript definitely had problem with those)

gosub100 3y ago
I was only tossing it out there as a token example. You can manipulate the heap in a minor way if you continually request and free memory in irregular ways (called mem fragmentation). Fixing the size (might) be one step towards hardening the system against OOM attacks. overall, I'm just wondering why we can't make C++ safe by starting at the lowest layers, mem-proofing them, and working up from there (and limiting/discarding some features along the way if necessary).

weinzierl 3y ago

We do, one approach is MISRA and it is ubiquitous in automotive.

UncleMeat 3y ago

"Ban a ton of widely used C++ features" creates a problem that is smaller than but still comparable to "rewrite it in rust." You also still have some features of modern defensive C++ that can still be abused and cannot be removed from the language or made safe without something resembling the Rust borrow checker. Getting these features in the C++ language itself will be absolutely impossible, both because of massive performance implications and well as nightmarishly large ABI breaks on everything. There are various efforts to do what you are describing. I think that they are often a good idea, but they absolutely will not solve the problem conclusively.