3 ms·
The most common memory safety bug in released software is array overflow. This is easily corrected in C by adding a small extension: https://www.digitalmars.co
by WalterBright 2y ago
The most common memory safety bug in released software is array overflow. This is easily corrected in C by adding a small extension:
https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html
- Gibbon1 2y agoThey could fix typeof to make it something useful. Like the ability to take the type of something and pass it around. And add slice and buffer typedefs to the standard library. Especially since they added counted_by to the language. Add a way to define a slice the points to a c string.
- ajb 2y agoYeah, but looking back at the attempts to extend C a bit for safety, the only one that seems to have got market traction is MISRA and even then it's pretty limited. D, rust, zig etc all seem to have much more buy in. There must be some reason why a new language works better here -I mean, you're basing your business off D, not a C extension, right?
- WalterBright 2y agoThis idea is just adapting the D version of it.
- ajb 2y agoThat's.. kind of my point. This mechanism has seen more adoption in a new language than in the existing language. I'm sure it would work technically - there must be some other reason why it's easier to get a new language adopted .
- EE84M3i 2y ago> The most common memory safety bug in released software is array overflow. Do you have a source for this? I thought it was use after free.
- tptacek 2y agoThat (or, more broadly, memory lifecycle bugs) would be my guess too.
- WalterBright 2y agoNot offhand, but every list of the common security bugs shows it's the top, by a wide margin.
- dcsommer 2y agoCWE Top 25: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html Out of bounds write and read are more prevalent then UAF. There are multiple types of bugs that can produce OOB read or write though.
- lmm 2y ago> This is easily corrected in C by adding a small extension It's so easy that thousands of developers trying for 40+ years haven't been able to do it yet.
- WalterBright 2y agoThey don't see the value in it. You have to use it a while to see how much time it saves you not chasing down memory corruption bugs.
- jcranmer 2y ago> This is easily corrected in C by adding a small extension Unfortunately, easily corrected it is not. Yes, probably >95% of arrays have a nearby easily-accessible length parameter that indicates their maximum legal length (excluding the security disaster of null-terminate strings). But the problem is there's no consistent way that people do this. Sometimes people put pointer first and size second, sometimes it's the other way around. Sometimes the size is a size_t, sometimes an unsigned, sometimes an int. Or sometimes it's not a pointer-and-size, but pointer and one-past-the-end pointer pair. Sometimes multiple arrays share the same size parameter. So instead of an easy solution getting you 90% for effectively free, you get like 30% with the easy solution, and have to make it more complicated to handle the existing diversity to push it back up to that 90%.
- WalterBright 2y agoThis extension was added in D at its start, and 25 years of experience with it shows that it is possibly D's best loved feature. It's a huge win.
- pjmlp 2y agoWhich WG14 keeps refusing to do, regardless of how often this is pointed out.
- WalterBright 2y agoI know, which was the motivation for D.