61–70 of 244 posts
Can someone please fix the title to the original in the blog ('Mitigating Memory Safety Issues in Open Source Software'), because the current title is not at all representative of what the blog is actually saying.
Edit: the submission title is fixed.
Why not contribute to MesaLock Linux, which is already an entire memory-safe Linux distribution instead? Or encourage other memory safe-languages as well?
So what's the point of reimplementing one-off-tooling with under the same name (like sh?!) in Rust, except adding confusion and new bugs? And in a container, you already can run only your rust/Go-program, which effectively means that the main memory-unsafe attack-surface is actually the kernel (which they don't swap out either).
C++, on the other hand, has a variety of choices for build systems. CMake is prevalent, you can use simple makefiles just like C, or you could use countless other custom solutions. I’ve found that languages which support a singular build system are really easy to build simple demo apps, but once you need to build something that the default build system doesn’t support, you’re in big trouble.
Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
Making C memory-safe by adding extra annotations to allow for static zoning/borrow checking is possible, but the churn involved is probably not much different than rewriting in a different language. See Cyclone for instance if you want to see what such an approach looks like.
On top of that modern languages have facilities that are seriously lacking from C, memory safe or not. C's error handling is atrocious, C doesn't have (standard) destructors, C doesn't have type inference, C doesn't have algebraic types, C doesn't have proper string/collection support etc...
I like C quite a lot, it's probably the language I know best, but it's definitely very outdated. I think in the not so far future it'll be almost entirely replaced outside of legacy applications, hopefully with Rust. I think the watershed moment will be when the Linux kernel is rewritten in an other language, which definitely won't happen overnight but at this point I'm fairly certain that it will happen within a couple of decades.
Earlier quoted context omitted.
The main strength of a memory-safe language is that the safety mechanisms are opt-out, not opt-in: you can confine the unsafe behavior to a small, manageable portion of the codebase. And trying to "fix" C to become a memory-safe language would probably just result in something like a Rust dialect that merely bears more superficial resemblance to C. In any case, thorough re-writing of existing codebases would be requi…
I would call C++ a memory safe language that has more than a superficial resemblance to C. Rust makes is more obvious when/where you are intentionally opting out, but most C++ memory bugs are where someone opted out of the modern C++ way to use the C way. (including new/delete as the C way).
C++ is not, in any sense, a memory safe language.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
Clearly, the C committee works hard on improving the language and they are in the process to standardize important features, such as lambda functions, auto, typeof (like C++'s decltype more or less), and so forth.
In my humble opinion, "defer" can mild the buffer / memory overflow, but of course not permanently remedied it 100%; to me though it's better to have such mechanism than have nothing at all to protect you.
https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...
Would not be cheaper to fix those unsafe languages, such as C, and offer safe mechanisms that could be used upon need? Why spend thousands, if not millions of dollars, on rewriting existing codebases when they could help fixing the existing toolset and make it safer? I don't get it.
To me this idea sounds a lot like "why do we need IPV6? Why not keep IPV4 and add a few bytes?" except it's effectively almost the same amount of breakage. Either you're C-compatible or you're not. Making C memory-safe by adding extra annotations to allow for static zoning/borrow checking is possible, but the churn involved is probably not much different than rewriting in a different language. See Cyclone for instanc…
While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity. There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. I'd say such an initiative needs a long-…
I could have got around it, but it took me by surprise that a Python dep required it. Not being negative or criticising the fact, just first time I had observed it.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
IIRC Zig isn't memory safe though, is it? If not it seems like a bad choice if the explicit purpose is to mitigate memory safety issues...