garbage collection makes not a language safe
Let’s sunset C/C++
61–70 of 137 posts
Re: Let’s sunset C/C++
#62This is quite ignorant of why C/C++ is used. It is used for that exact memory control and access that this article demonizes so that we can have efficient and thought out systems. When those systems aren't well thought out or secure you have security issues. C/C++ lets you build a wobbly treehouse _and_ a secure fortress. It is up to the developer which one is made...
> When those systems aren't well thought out or secure you have security issues. All evidence says that there are no well thought out and secure systems written in C or C++. If there is a way to do it, it has not been publicized yet.
There are no secure systems written in ANY language (to my knowledge).
At the end of the day all computers and systems can be broken. Using C/C++ might open up that up to being more likely when someone isn't thoughtful enough in the implementation. The trade off comes in when you want to risk the higher chance of security problems for the better performance.
This is just my opinion, I believe that we spend way too much time writing in these 'safe' languages at the cost of performance when it often isn't really needed and in the long run just adds to the bloat of our systems. This comes from my belief that if anyone is willing to spend the time and money to break a system they will. So why are we burdening our piggy banks with the same security as our bank vaults?
Re: Let’s sunset C/C++
#63So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what? Sure make every numeric value a double, nobody ever wants a char. Don't allow contiguous blocks of memory. Or if you do check every access is within the bounds. Its all safe! Nobody cares that suddenly we can't decode an MP3 in realtime. Are you going to outlaw assembly too? What utter insanity.
> So what language to you propose we use to rewrite all video and audio software? Javascript, Lua, Brainfuck, what?
It's not proposing a particular language; only a property was proposed: memory-safety. This was defined loosely:
> Garbage collection was invented in 1959, for Lisp, the first memory-safe language. It provides the foundation for memory safety and it is used in most memory-safe programming languages today. (It is also possible to have memory-safe languages without garbage collection, e.g., Cyclone or Rust.)
We could compare this with other properties of programming languages which have been tried in the past, but are now considered bad ideas or a last resort:
- DWIM (Do What I Mean): if a name (function, variable, etc.) doesn't exist, use one with a similar spelling
- Ignore errors by default: eg. Bash without "set -e", visual basic's "On Error Resume Next", etc.
- GOTO: still useful on occasion, but no longer the "go to" control structure in most code (pun intended)
- Dynamic scope by default
- NULL: Perhaps controversial, but also infamous. Can be tamed with nullable types, or eliminated with option types.
- "Loose typing", ie. the casting rules in PHP, JS, etc. which break symmetry and transitivity of "=="
- Automatic semicolon insertion: Either require semicolons or don't; trying to guess leads to problems
- Name-based typing: eg. in FORTRAN any variable name beginning with I, J, K, L, M or N are implicitly ints, anything else is implicitly float
I would certainly consider memory unsafe languages in the same category. There's no need, now that we have garbage collection and linear types.
Re: Let’s sunset C/C++
#64Earlier quoted context omitted.
You are joking in regards to OpenSSH right?
No, not at all. It's likely the most secure remote access software that you could use. http://www.openssh.com/security.html
Re: Let’s sunset C/C++
#65Earlier quoted context omitted.
> This is quite ignorant of why C/C++ is used. C and C++ are used due to UNIX becoming widespread, opening the door to those languages in the industry, and killing safer systems programming languages in the process. The majority of security exploits in C and C++ aren't possible in Modula-2, Ada, Algol, just to cite a few examples. To quote Hoare on his award's speech, The Emperor's Old Clothes: "Many years later we a…
Becoming widespread? Outside the desktop, the most commonly used operating system is Unix and its "likes" and dominates the internet and mobile devices.
I only cared about C in 1993 and am into computers since 1986.
Only developers with access to expensive UNIX workstations cared about learning C.
Yes, the widespread of UNIX and C as its language is one of the reasons the CVE database gets updated every day.
Re: Let’s sunset C/C++
#66Earlier quoted context omitted.
No need to panic, nobody is coming to take your precious pointer arithmetic away. If you want to write unsafe code, go ahead. But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. We're talking about classes of security bugs that just don't exist in managed languages. Bugs that can't happen in languages like Rust either because it forces programmers to indicate ownership…
>But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. You can't write safe code in any Turing complete language. That's the whole point of Turing completeness. The only reason why memory attacks are as common as they are is because C like languages are the most popular ones. If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd h…
> If we replaced everything written with C to a "safe" language like, I don't know Haskell?, we'd have just as many zero day exploits of the monads within programs.
I disagree. There will always be security issues, due to (ab)uses that developers didn't consider, but there can be different probabilities. Requiring developers to learn about language gotchas, remember those gotchas when coding, and jump through hoops to avoid them, just stacks the odds against us.
Re: Let’s sunset C/C++
#67Excuse my french, but: What a load of bullshit. It's not the language, it's the tools. Add a static analyzer pass to each C/C++ compiler which is switched on by default. Add clang-address-sanitizer-style code when compiling in debug mode, and also offer runtime checks as option for release-compiled code. Both combined would have caught 99% of memory safety issues that pop up now and then. If necessary extend the lang…
I don't understand this type of reaction every time the problems of C/C++ are highlighted. Yes, of course the problems can be migitated using tools, but clearly this is not being done or is not as thorough or practical a solution as making it the language's responsibility. There's hoops that you must jump through to make C/C++ safe and clearly this just doesn't happen in practice. The same hoops just don't exist for…
Rust is the right approach since it figures everything out at compile time. But it still has to prove itself. And what is the timeline for a browser completely re-implemented in Rust? 5 years? 10 years? Suggesting that throwing away and rewriting our entire software foundation that has been written in the past 50 years is just silly. To be realistically achievable we need an incremental approach to gradually analyze and fix old software instead of throw-away-and-rewrite.
Re: Let’s sunset C/C++
#68Earlier quoted context omitted.
This argument is very flawed, since you are forced to use `unsafe` when you need anything communicating to the outside world (which includes, obviously, `println!`). The very point of Rust is to limit the unsafe surface, not to completely eliminate that.
First of all a graph library does not communicate with the outside world. My point was that even for the ubiquitous task of implementing a graph structure, unsafe is necessary. So while Rust may provide a clean separation between unsafe and safe code (enforced by the type system), the original problem remains: How do we ensure correctness of the unsafe parts of the code.
For what it's worth (and I intentionally didn't point this out in the parent), you can make a safe graph library in Rust with a typed arena (slightly less ergonomic and faster) or a refcounted smart pointer (slightly more ergonomic and slower). But this still does not validate your point, since the memory allocator is in many cases unsafe.
On how to ensure correctness of the `unsafe` code: that was what we were doing with the entire C/C++ code for decades, so what's the problem? We could however concentrate on the much less amount of code if we were using safer languages.
Re: Let’s sunset C/C++
#69Excuse my french, but: What a load of bullshit. It's not the language, it's the tools. Add a static analyzer pass to each C/C++ compiler which is switched on by default. Add clang-address-sanitizer-style code when compiling in debug mode, and also offer runtime checks as option for release-compiled code. Both combined would have caught 99% of memory safety issues that pop up now and then. If necessary extend the lang…
To a degree this ammuses me greatly. Rust allows you to opt-out of safety. While your proposal (which I agree with to be clear) allows you to opt-in to safety in C/C++. This really cuts to the core of ideological differences between C/C++ and Rust camps. C/C++ programmers tell the compiler trust me , while Rust programmers say check me . I can't help but feel to a degree the Rust ideology is superior. To make by bias…
To be clear, I love Rust's approach to safety. I just don't think it is an realistic expectation that we can re-implement all security-critical C code in Rust until the sun goes super-nova ;)
Re: Let’s sunset C/C++
#70To this, I can only agree. I love C and I can write secure software in it, but the costs of doing that are generally not worthwhile in today's market (if they ever were). C will still have a place in its niche, but it shouldn't be considered the standard general-purpose language any more. Our processors have gotten so fast we can run slow-motion versions without even noticing (smartphone & tablet CPUs), so don't tell…
Memory-safety doesn't make a language slower. Garbage collection does, but there are other approaches like linear types which perform all checks at compile-time, so the resulting code doesn't need to do any checking/indirection/etc. and is hence equivalent to what C would produce.