Ah, they must have found an exploit in Rust then
Or... (puts on tin foil hat) added it themselves.
As a C++ programmer, I really want to find a spare week or two to learn Rust.
The Case for Memory Safe Roadmaps
231–240 of 427 posts
Re: The Case for Memory Safe Roadmaps
#232Can 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-s…
We do, one approach is MISRA and it is ubiquitous in automotive.
Re: The Case for Memory Safe Roadmaps
#233welcome to javascript
Re: The Case for Memory Safe Roadmaps
#234Given the vast amount of C/C++ around, much which will never be rewritten, I wonder if bounds checking compilers should be considered?
Bounds checking will sure solve some of the problems, but it will not solve all of them, perhaps not even most of them. You'd still got: UAF, iterator invalidation, etc.. And not even all code can be bounds checked, you need to know the length for that (which means using new types such as std::span or having to annotate your functions with a compiler attribute, to be able to also bound-check pointers).
Bounds checking is also frustratingly expensive because of C++'s horrible aliasing rules meaning that compilers struggle to soundly eliminate redundant bounds checks.
Re: The Case for Memory Safe Roadmaps
#235Earlier quoted context omitted.
> absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). Meta have a phenomenally good training program, called Bootcamp for basically everyone in engineering, so they're probably not the example you're looking for.
I recall meta expects new hires to do first commit the first day, not sure how its training will help in this scenario, this is in no way saying meta has no good training, it just does not add up here though.
What kind of commit though? We expect a first commit on the first day. The commit adds you to the maintainers list in readme and grants you some new roles after merging. It is not a "solve this user's issue" kind of commit.
Re: The Case for Memory Safe Roadmaps
#236Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
You can also cause a segfault in Go by dereferencing a null pointer. That's another example of not being entirely memory safe.
Re: The Case for Memory Safe Roadmaps
#237Earlier quoted context omitted.
Startups are likely to fail, big tech is likely to fire the developer (or they quit), and poorly run companies just don't know how to train. End result is it just doesn't happen much anymore.
Employers complain they can't find people with the skills they need yet they refuse to provide training for those skills as it's cheaper to hire someone that was trained in the skills they need by another employer.
> yet they refuse
That doesn't seem like a contradiction at all. As you say, they want to hire trained workers rather than providing training themselves. Also, complaining is free while hiring good people is not...
Re: The Case for Memory Safe Roadmaps
#238Earlier quoted context omitted.
Based on early days of Rust in the Linux kernel, the segmentation of safe and unsafe code can significantly reduce the surface area within a kernel.
I realize this is beating a dead horse, but it really is a shame that microkernels didn't win for human-facing Unix systems. This issue was recognized and basically solved decades ago, and we're still almost there.
This is true for server systems too. I've often had problems which were ultimately only solvable by rebooting large fleets of servers.
Had the servers been running microkernels instead, updating services without full restarts would have been trivial in almost all cases.
It's just a better approach overall. I curse the path dependency that led to the current situation.
Re: The Case for Memory Safe Roadmaps
#239Earlier quoted context omitted.
Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…
Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…
> Why are C and C++ considered the same, in these conversations?
Conjunction is not equality. They are both memory unsafe. Then you can argue from that over how memory unsafe they are in practice (using the right practices, using the right language subset).
Re: The Case for Memory Safe Roadmaps
#240Earlier quoted context omitted.
Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark
Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?
Also weapon systems.