Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s sunset C/C++

trevorjim.com

Post reply on HN
Print view View original

51–60 of 137 posts

Re: Let’s sunset C/C++

#51

Post by flohofwoe »

sdf45 wrote: post #43
flohofwoe wrote: post #30

Excuse 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…

While tooling may help, I think that a completely new approach is necessary. The correctness invariants of complex C++ programs (such as browsers and JITs) cannot be 'discovered' by static analysis - they must be, at least in part, supplied by the programmer. C and C++ were not designed to allow programmers to specify such invariants (and have them automatically checked). I am not convinced that introducing them can…

Hmm true, we could have a new 'safe' keyword (or even #pragma) which would switch off 'unsafe' language features (basically the opposite of Rust's 'unsafe' enforce a stricter, more restrictive code style which is easier for the static analyzer to reason about). The majority of even high-performance C/C++ apps only needs to twiddle bits in very small areas of the code. That's still a lot better then trying to rewrite basically all software that has been written in the last 50 years ;)

Re: Let’s sunset C/C++

#52

Post by jganetsk »

sdf45 wrote: post #34
zamalek wrote: post #23

Earlier quoted context omitted.

I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find). I also hope to end C/++, but it's simply not time yet.

Please show me how to implement a graph library without using unsafe in Rust.

Several answers to this challenge

1) It's doable http://smallcultfollowing.com/babysteps/blog/2015/04/06/mode...

2) Which attack surface would you rather deal with... the small fraction of your graph library that deals with mutability... or all of Adobe Flash?

3) The fact is that "unsafe" doesn't mean unsafe, it means "trust the programmer that this is safe". It's reasonable to assume that safety can be maintained in Rust libraries that use the unsafe keyword.

Re: Let’s sunset C/C++

#53

Post by jganetsk »

J2Alpha wrote: post #50

I do appreciate a good troll once in a while but they shouldn't rise to the top page of HN. It gives them ideas above their station. I have a burning question tough, What pray tell safe language would you use to write the original garbage collector, because Garbage collecting is only a form of abstracting good pointer practices away, helping programmers write complex programs easily.

Who said anything about a garbage collector?

https://www.rust-lang.org/

Re: Let’s sunset C/C++

#54

Post by sdf45 »

lifthrasiir wrote: post #46
sdf45 wrote: post #34

Earlier quoted context omitted.

Please show me how to implement a graph library without using unsafe in Rust.

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.

Re: Let’s sunset C/C++

#55

Post by bowlofstew »

Timmons wrote: post #5

This 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...

I couldn't agree more. I like how he is very pointed at C/C++ and doesn't mention any of the safer, garbage collected languages....OH NOES, they have issues too!

Java: https://www.exploit-db.com/exploits/36101/

.NET: https://www.exploit-db.com/exploits/35280/

Python: https://www.exploit-db.com/exploits/33251/

At least my code/data running in "the cloud" is safe:

http://www.jcomputers.us/vol9/jcp0904-30.pdf

https://www.cs.unc.edu/~reiter/papers/2012/CCS.pdf

I can keep going here but you get the point. Perhaps he should have also taken it further and proposed that we move onto Mill processors since the underlying hardware has a history of issues:

sinkhole: https://www.exploit-db.com/exploits/37724/

rowhammer: https://www.exploit-db.com/exploits/36310/

Yes in C/C++ you can make mistakes (#gotofail) but in other languages, I would argue you can fuck-up in ways that are not nearly as obvious such that static analysis can't catch. A nicety about C/C++ is the tooling has gotten pretty damn good over the last 43 years (clang, gcc, valgrind, etc) and can catch most of these kind of bugs. The onus is on the developer to do the correct thing though and it appears that over at Adobe, etc that they (historically) could give 0 shits about doing this. It honestly seems to be though, that they are tightening up things.

Perhaps we should rebuild everything from the ground up....

Re: Let’s sunset C/C++

#56

Post by DCKing »

flohofwoe wrote: post #30

Excuse 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 Go and Rust (and that's just the system(ish) programming languages) and therefore I disagree that you can handwave this away as bullshit.

Re: Let’s sunset C/C++

#57

Post by valarauca1 »

flohofwoe wrote: post #30

Excuse 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 clear I work in C, and write in Rust in my spare time.

Re: Let’s sunset C/C++

#58

Post by monochr »

gizmo wrote: post #49
flohofwoe wrote: post #30

Excuse 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…

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 have just as many zero day exploits of the monads within programs.

Re: Let’s sunset C/C++

#59

Post by zamalek »

sdf45 wrote: post #34
zamalek wrote: post #23

Earlier quoted context omitted.

I suppose the answer would be Rust or similar because they aim to be as fast as C/++; however, that is currently only a goal and most certainly not the reality (according to some source I read a month or two back that I can no longer find). I also hope to end C/++, but it's simply not time yet.

Please show me how to implement a graph library without using unsafe in Rust.

I've never actually used Rust myself - I'm just familiar with their goals: so I'm not entirely sure what you are referring to.

Just keep in mind that the amount of work done on the various C++ compilers is most likely measured in man-decades, where Rust is probably still man-hours.

Do you mean a directed graph or a graphical graph? I've implemented directed graphs in at least two different managed languages (which are more constrained than Rust) and had to use no unsafe breakouts. There might be some complexity for some reason with Rust, but if it's possible in a managed language then surely...

Re: Let’s sunset C/C++

#60

Post by epidemian »

sdf45 wrote: post #32

As of yet, a browser (in particular the JavaScript JIT) cannot be implemented in a safe language. It is not even clear how a safe language that would permit this would look like. Thinking that banning C/C++ magically solves all problems is naive.

> It is not even clear how a safe language that would permit this would look like.

If this hypothetical browser is implemented in a safe language that runs on a JIT-compiled environment itself, then it could compile JS to that same safe language and allow that same runtime environment to JIT-compile the resulting compiled JS.

Would that make sense? (I have no empirical data to back this up, but i'd like to know if at least hypothetically this approach could work)

Post reply on HN