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

91–100 of 137 posts

Re: Let’s sunset C/C++

#91

Post by [deleted] »

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…

[deleted]

Re: Let’s sunset C/C++

#92

Post by notacoward »

"This is a huge job"

I don't think the author fully appreciates just how huge, and how many new bugs would be introduced by rewrites on that scale. It might be reasonable to say C/C++ should be deprecated for new projects, but truly vast amounts of C/C++ will remain with us for the foreseeable future. Perhaps a better approach would be to ease integration of new code written in memory-safe languages with older code written in C/C++, which tends to be tedious at best nowadays.

Re: Let’s sunset C/C++

#93

Post by RotsiserMho »

JustSomeNobody wrote: post #27
fiedzia wrote: post #4

Earlier quoted context omitted.

Rule 20.4 (required): Dynamic heap memory allocation shall not be used. Good luck writing misra-compliant web browser. And yes, safe languages can be written in safe languages. See rust and servo.

"... misra-compliant web browser." Surely this is a joke.

I so wish it were.

Re: Let’s sunset C/C++

#94

Post by pjmlp »

JoeAltmaier wrote: post #85
pjmlp wrote: post #82

Earlier quoted context omitted.

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.

Yes, that is why I find it good that both Mac OS X and Windows allow for kernel code in C++ as a kind of "worse is better" improvement over plain C.

However C++ with teams that haven't drink the safety kool aid, becomes C with a C++ compiler quite fast.

Hence why nowadays I tend to only use it occasionally in side projects.

Re: Let’s sunset C/C++

#95

Post by kevingoslar »

flohofwoe wrote: post #69
valarauca1 wrote: post #57

Earlier quoted context omitted.

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 ;)

It's probably not going to be a rewrite of existing systems, but a switch to new systems written in safer languages while phasing out the old C based systems.

On the server: unikernels. On the client: new mobile platforms, like OSes based mostly on web technologies (which while not quite being there yet are getting more and more powerful).

C/C++ is not only a poor choice in regards to security, but also to develop for hardware with hundreds or thousands of cores, and all hardware platforms are moving in that direction. Yes there are of course ways to deal with that in C/C++, but other languages are much better at this.

Within just a decade or two I can see a fundamental shift away from the old computing paradigm, at least for the majority of systems in mainstream use.

Re: Let’s sunset C/C++

#96

Post by rrss1122 »

"I don’t see many people in the security industry taking up this call..."

http://www.viva64.com/en/b/0324/ [Criticizing the Rust Language, and Why C/C++ Will Never Die ]

"It is crystal clear for every sane programmer that C/C++ is not going to die in the nearest future. No one is going to rewrite almost all of the existing desktop applications, operating system kernels, compilers, game and browser engines, virtual machines, databases, archivers, audio and video codecs, tons of other C-libraries, and so on and so forth, into other languages. This is a huge mass of fast, debugged, and time-proven code. Rewriting it is way, way too expensive, risky, and, honestly, doesn't seem to make sense except in the heads of the most frantic Rust fans. The demand for C/C++ programmers has always been high and will remain so for a long time to come."

Seems like just more proselytizing from Rust fans looking to expand their ranks. Of course more people in the security industry are not taking up this call, because it is a ridiculous suggestion.

Re: Let’s sunset C/C++

#97

Post by GFK_of_xmaspast »

tempodox wrote: post #22

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

All that extra computation load directly translates to increased power consumption and reduced battery life.

Re: Let’s sunset C/C++

#98

Post by piva00 »

JoeAltmaier wrote: post #81
gizmo wrote: post #73

Earlier quoted context omitted.

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.

I didn't understand how Java relates to his comment about JavaScript + Python.

Re: Let’s sunset C/C++

#99

Post by rrss1122 »

pjmlp wrote: post #64
w8rbt wrote: post #28

Earlier quoted context omitted.

No, not at all. It's likely the most secure remote access software that you could use. http://www.openssh.com/security.html

Except when it isn't http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial... http://www.cvedetails.com/vulnerability-list/vendor_id-97/pr...

Any secure remote access software is the most secure, except when it isn't. This is a tautology, doesn't reveal any deep insight.

Re: Let’s sunset C/C++

#100

Post by pjmlp »

rrss1122 wrote: post #99
pjmlp wrote: post #64

Earlier quoted context omitted.

Except when it isn't http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial... http://www.cvedetails.com/vulnerability-list/vendor_id-97/pr...

Any secure remote access software is the most secure, except when it isn't. This is a tautology, doesn't reveal any deep insight.

The point being that the amount of available exploits shows it is far from being secure.
Post reply on HN