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

41–50 of 137 posts

Re: Let’s sunset C/C++

#41

Post by peterwaller »

JustSomeNobody wrote: post #15
peterwaller wrote: post #7

Earlier quoted context omitted.

A place where your reasoning breaks down is when one comes to define "the developer". There are a few legendary developers in the world I would trust to write secure C/C++. Others may be able to do so, by luck. Would I trust an organization of 2000 people all developing the same large code base? I know there are processes that can be adopted, such as using clever static analysis tools and rigorous review by security…

This will happen regardless of C or C++.

I agree with this and bilbo0s. There exists no panacea. But C/C++ leave a lot of unholstered footguns lying around to play with :)

Re: Let’s sunset C/C++

#42

Post by carlosrg »

C++11 is pretty "memory safe". But obviously it allows the programmer go low-level and deal with dangling pointers if he/she wants. After all, the programmer/engineer is supposed to be a professional that can handle these things and make autonomous decisions.

Re: Let’s sunset C/C++

#43

Post by sdf45 »

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 be done in a clean way.

Re: Let’s sunset C/C++

#44

Post by justwannasing »

pjmlp wrote: post #13
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...

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

Re: Let’s sunset C/C++

#45

Post by [deleted] »

tempodox wrote: post #36
J_Darnley wrote: post #12

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

Never panic early. Look e.g. at Rust - just as efficient, much more secure.

[deleted]

Re: Let’s sunset C/C++

#46

Post by lifthrasiir »

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.

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.

Re: Let’s sunset C/C++

#48

Post by justwannasing »

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…

Niche? C and Java are the most used languages in the world!

Re: Let’s sunset C/C++

#49

Post by gizmo »

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 and lifetime of memory.

There's always a trade-off between performance and security, but with better tooling support the price for secure code will be very low. Right now security is bad because we look at security as a feature. As something that is added to a project, instead of as something that guides the entire design.

Your suggestion that static analysis can fix this is wildly optimistic, because C/C++ code for a modern browser uses memory pools, pointer arithmetic, just-in-time compilation, and shared memory between object instances, threads and processes and so on. It's hugely complex, and correctness can't be verified with some sort of static analyzer or with added runtime checks.

Re: Let’s sunset C/C++

#50

Post by J2Alpha »

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.

Post reply on HN