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

81–90 of 137 posts

Re: Let’s sunset C/C++

#81

Post by JoeAltmaier »

gizmo wrote: post #73
monochr wrote: post #58

Earlier quoted context omitted.

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

There is a huge difference between a program that computes the wrong answer and one that corrupts memory, hijacks a shell, and installs a rootkit. Javascript is turing complete but it's trivial to write a (slow) javascript interpreter in Python that allows anybody to run any javascript program without any risk to their machine. No memory attacks possible. To privilege escalation possible. No unchecked stack overflows…

For pure Java perhaps. But native code is inevitable, and it has no such protection. So in practice Java is not a lot of protection.

Re: Let’s sunset C/C++

#82

Post by pjmlp »

carlosrg wrote: post #76
gizmo wrote: post #49

Earlier 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++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want . Memory pools are not a C++ feature, memory pools are part of how…

I like C++ and dislike its C foundation.

Always written C++ taking advantage of the language features that allow for safer code and bring it closer to Ada linage than C.

Never saw anyone else doing the same in the enterprise codebases I worked on. My team at CERN was the only exception.

Re: Let’s sunset C/C++

#83

Post by pjmlp »

valarauca1 wrote: post #57
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…

There is a big difference opting out of safety and having to opt into safety in every code line one writes.

Safer systems programming languages were already available outside AT&T when C was born. Rust is just the latest addition to them.

Re: Let’s sunset C/C++

#84

Post by RegW »

bowlofstew wrote: post #55
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://ww…

Hmm - the Java attack seems to assume that a JMX server has not been configured to authenticate requests, can be connected to using RMI and has no class loader security manager.

I'm not sure this is really a problem with the Java language, or even the programmer. If I leave my front door wide open, I don't think I can blame the lock for failing to do its job.

Re: Let’s sunset C/C++

#85

Post by JoeAltmaier »

pjmlp wrote: post #82
carlosrg wrote: post #76

Earlier quoted context omitted.

> But we also have to acknowledge that we as a profession are not able to write secure code in C/C++. Wrong. You can write perfectly safe code in C++. You seem to have this ridiculous idea that pointer arithmetic is mandatory on C++. "Pointer arithmetic" is not a feature of C++. It's a feature of how computers work. C++ allows you to do it if you want . Memory pools are not a C++ feature, memory pools are part of how…

I like C++ and dislike its C foundation. Always written C++ taking advantage of the language features that allow for safer code and bring it closer to Ada linage than C. Never saw anyone else doing the same in the enterprise codebases I worked on. My team at CERN was the only exception.

You can even write C++ without linking the runtime, to avoid all that unsafe legacy code. For drivers and such. Done it many times.

Re: Let’s sunset C/C++

#86

Post by pjmlp »

p0nce wrote: post #40

C++ is safe enough, provided you use the tools like Intel Inspector, valgrind, and static analyzers. With C++11 memory corruptions became a somewhat rare occurence.

Which most developers actually don't use, specially the 9-5 developers.

Re: Let’s sunset C/C++

#87

Post by sklogic »

monochr wrote: post #58
gizmo wrote: post #49

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

> You can't write safe code in any Turing complete language.

Correct. But, a lot of code is written in Turing complete languages which does not really require any Turing completeness at all. And some code should be implemented in non-Turing-complete, verifiable languages.

Re: Let’s sunset C/C++

#88

Post by andresmanz »

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

Then you've picked the wrong profession. You write that like it was a fact, while it's obviously nothing more than a lack of skill (and maybe knowledge) on your side.

If I chose a language primarily because it's 'safe', that would mean that either I'm pretty bad at writing safe code, or that I'm just unnecessarily lazy.

Re: Let’s sunset C/C++

#89

Post by sklogic »

gizmo wrote: post #73
monochr wrote: post #58

Earlier quoted context omitted.

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

There is a huge difference between a program that computes the wrong answer and one that corrupts memory, hijacks a shell, and installs a rootkit. Javascript is turing complete but it's trivial to write a (slow) javascript interpreter in Python that allows anybody to run any javascript program without any risk to their machine. No memory attacks possible. To privilege escalation possible. No unchecked stack overflows…

It must be really slow in order to avoid attacks like this one: https://github.com/IAIK/rowhammerjs

Re: Let’s sunset C/C++

#90

Post by charlesL »

Ugh... these kinds of extreme posts really piss me off. Yes, C is unsafe. Yes, there are safer higher level languages, but there's a reason C is used. Because it's REALLY freaking fast, and allows you to actually tune how memory is used.

The issue with C is not the language itself. It's the complexity of the project. Once a project reaches a certain size, no programmer will be able to keep the entire thing in their head at one time. That's why the bugs appear.

I have no issue with saying that C is hard to work with in giant projects. If you have an issue with that, write the sections of code that bottleneck in C, and then glue them together with a higher level language (I personally like Lua for this).

Also, the post is mainly complaining about security issues for Chrome. Assuming Chrome is rewritten in Rust or Go, will these security issues vanish? Of course not. Bugs (especially security bugs) will exist in all software, whether it's written in C or Ruby.

So the results of rewriting all C code in the world is: slower, less optimized code and continued existence of security bugs. Sounds great.

Post reply on HN