Earlier quoted context omitted.
Then you don't know anything about C++, only the C legacy it is built on. Modern C++ has good data structures and good memory management. To be fair actually using those features of C++ instead of the C legacy is still catching on. Most instructors aren't even teaching it. Using C in C++ is like using unsafe everywhere in rust - you can do it, but you lose all the advantages.
This is a common viewpoint but also wrong. There's plenty of ways to invoke memory unsafety in 'modern' C++: iterator invalidation is probably the biggest source.
Mitigating Memory Safety Issues in Open Source Software
201–210 of 244 posts
Re: Mitigating Memory Safety Issues in Open Source Software
#202Earlier quoted context omitted.
Or Ada or Wuffs But I have always used Pascal for that. It has memory safe strings and arrays with refcounting, so long as one avoids using other features like pointers, classes, inline assembly, it is perfect.
Wuffs? Never heard of that one before. Edit: here's the link, interesting idea. https://github.com/google/wuffs
The memory-safe languages can still panic or have integer overflows, Wuffs should prevent even that
Re: Mitigating Memory Safety Issues in Open Source Software
#203Earlier quoted context omitted.
This is a common viewpoint but also wrong. There's plenty of ways to invoke memory unsafety in 'modern' C++: iterator invalidation is probably the biggest source.
While you are technically correct, those who study C++ security note that those are a tiny minority of all security errors. Still an issue, but not nearly as common an issue as the ones that come from the C roots of C++.
https://en.wikipedia.org/wiki/No_true_Scotsman
Also can you link to an example of this purported memory safe C++ compiler? Please note for an apples to apples comparison it must reject all memory unsafe non-modern C++ constructs.
Re: Mitigating Memory Safety Issues in Open Source Software
#204A worthwhile goal. But not in a memory unsafe language, please. There's hype and there are lies: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...
This is flamebait, ignoring that "nearly perfect detection" and "no detection whatsoever" are very different things. But also, stack overflows aren't memory unsafe in modern rust. The issue search you want to find memory safety issues is: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...
Your query searches for type unsafeties. A third query would be for concurrency unsafety: deadlock. All three unsafeties are builtin by design. There's no way to deny it. But they still do repeat the same lies again and again.
Stack overflows being memory safe you can tell your grandma or upper management. Problem was rust was once memory safe, but they ripped out the GC. Now it's just better than C++, but not better than Java or really safe languages. Overhype rarely reflects well on a community.
Re: Mitigating Memory Safety Issues in Open Source Software
#205Earlier quoted context omitted.
Their accountants probably prefer this route though. They don't get a competitive advantage by have a proprietary license, so open source is a good choice, but the GPL has issues they want to avoid. By going this route they can use tax breaks that are not available for doing the work in house. Sure it is more complex, but the results matter, and the result they are hoping for is someone else does work that they don't…
What kinds of tax breaks are available for the case of using consultants instead of employees?
There are a lot of tricks needed to make the above work, and details that you need to consult a lawyer and accountant for.
Re: Mitigating Memory Safety Issues in Open Source Software
#206Earlier quoted context omitted.
Yeah, it sounds a lot like Google is going to "hijack" popular open source projects for the sake of "security". It'll be interesting to watch how this plays out. But I pity the projects where Google's gaze falls upon.
I’m not sure “hijack” is the right word. They are using money to entice projects to rewrite in memory safe languages.
Re: Mitigating Memory Safety Issues in Open Source Software
#207Re: Mitigating Memory Safety Issues in Open Source Software
#208Earlier quoted context omitted.
Is it not a bit of a paradox that said embedded platforms matter enormously right up to, but not including the point of having toolchains ported to them and maintained? And yes while gcc can be built to produce binaries for an alpha it's not producing any bugs right?
The interests of people writing new language toolchains sadly does not seem to extend to supporting older platforms. This doesn't mean that they are not important, it just means that that they are not important to the people writing the new language toolchains.
Re: Mitigating Memory Safety Issues in Open Source Software
#209Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries. Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime. But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memo…
Re: Mitigating Memory Safety Issues in Open Source Software
#210Earlier quoted context omitted.
The interests of people writing new language toolchains sadly does not seem to extend to supporting older platforms. This doesn't mean that they are not important, it just means that that they are not important to the people writing the new language toolchains.
It's not a matter of interest; if an embedded platform matters they should be willing to pay someone to port Rust.