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

71–80 of 137 posts

Re: Let’s sunset C/C++

#71

Post by cautious_int »

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…

Mill processors? Aren't they still in research stage, only using emulation and no hardware.

Re: Let’s sunset C/C++

#72

Post by samuellb »

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.

I think the main reason we aren't moving away from C and C++ is interopability, and not performance. I can come up with a number of benefits of C in this regard:

1) Ability to use existing libraries directly (just #include and add to LDFLAGS).

2) Ability to be called (as a library) by code written in almost any language, without indirection through serializing function calls or similar.

3) Modern operating systems can share code and constant data sections between processes for normal compiled programs (but not byte-compiled ones).

4) C has a good tool support, such as debuggers and packaging tools for Linux distributions.

5) A practice of backwards-compatibility in the C language and libraries written in C makes it possible to mix code that was written for different versions of C or that use different versions of the same library.

Re: Let’s sunset C/C++

#73

Post by gizmo »

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…

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. The system would be sandboxed and secure. It will just work or fail gracefully.

It's only when we increase the complexity of our runtimes a thousand fold and when we cut corners to squeeze out higher performance that all the nasty vulnerabilities start to creep in.

Re: Let’s sunset C/C++

#75

Post by sklogic »

quonn wrote: post #9
sklogic wrote: post #6

Earlier quoted context omitted.

> Good luck writing misra-compliant web browser. I'd be delighted to see one. Statically pre-allocating a large continuous chunk of memory for the whole browser process lifetime would have been great.

And then, what do you do with that chunk? Since the amount of memory you need depends on the website (e.g. some might need memory for a canvas, others might display large tables, etc.), presumably you take parts of it and allocate them for the various tasks you need to do? So you just write your own dynamic memory allocator.

> So you just write your own dynamic memory allocator.

If the entire pool is reclaimed once page is rendered (and there is a way to handle the running out of space condition) it may not count as a rule violation, no more than incrementing an array index counter.

And, browser is hardly a mission-critical appliance.

Re: Let’s sunset C/C++

#76

Post by carlosrg »

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

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 a modern computer and OS works. You know, memory doesn't appear magically in your program.

> Rust forces programmers to indicate ownership and lifetime of memory

So like C++ with unique_ptr, shared_ptr, and RAII?

Also I wanted to say that some of you keep mixing C and C++, calling them "C/C++". They're two different languages.

Re: Let’s sunset C/C++

#77

Post by tempodox »

justwannasing wrote: post #48
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!

Niche as in “where it makes sense to use it because the strengths of the language support your important goals and the weaknesses don't kill you” as opposed to using it because it's one of the most used languages in the world.

Re: Let’s sunset C/C++

#78

Post by cousin_it »

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.

It seems to me that an undirected graph can be represented as a map from keys to sets of keys (which can be integers, strings, or anything else), with the invariant that map[x] contains y iff map[y] contains x. For a directed graph, use two maps for incoming and outgoing, with the invariant that incoming[x] contains y iff outgoing[y] contains x.

This approach doesn't require unsafe anywhere and all graph operations are easy to implement, including deleting nodes. Am I missing something?

Re: Let’s sunset C/C++

#79

Post by justwannasing »

tempodox wrote: post #77
justwannasing wrote: post #48

Earlier quoted context omitted.

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

Niche as in “where it makes sense to use it because the strengths of the language support your important goals and the weaknesses don't kill you” as opposed to using it because it's one of the most used languages in the world.

Which emphasizes my point. There are few places where C's strength is not prevalent and its weaknesses won't kill you.

Re: Let’s sunset C/C++

#80

Post by justwannasing »

My problem with this article and its statement is that it's saying to "sunset" C/C++ because it causes problems but the problems are caused by an incompetent user, not C.

I see so many articles complaining about C letting you shoot yourself in the foot but no one who would shoot themselves in the foot should be handling a gun.

"You know you wouldn't have so many splatters on that painting, Mr. Pollock, if you would just let a computer handle that brush for you!"

Post reply on HN