Let’s sunset C/C++

31 点作者 vu3rdd将近 10 年前

23 条评论

flohofwoe将近 10 年前

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 language with optional ownership keywords a'la Rust, and allow me to switch off features I don't require to reduce complexity.Most important of all: provide options that I don't need to pay at runtime for memory safety with precious CPU cycles.

评论 #10059684 未加载

评论 #10059653 未加载

评论 #10059691 未加载

评论 #10059632 未加载

评论 #10059618 未加载

Timmons将近 10 年前

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

评论 #10059561 未加载

评论 #10059523 未加载

评论 #10059682 未加载

评论 #10059578 未加载

评论 #10059524 未加载

J_Darnley将近 10 年前

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.

评论 #10059704 未加载

评论 #10059581 未加载

评论 #10059753 未加载

评论 #10059562 未加载

评论 #10059594 未加载

评论 #10059607 未加载

评论 #10059614 未加载

评论 #10059568 未加载

charlesL将近 10 年前

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.

评论 #10060482 未加载

评论 #10064532 未加载

rrss1122将近 10 年前

"I don’t see many people in the security industry taking up this call..."<a href="http://www.viva64.com/en/b/0324/" rel="nofollow">http://www.viva64.com/en/b/0324/</a> [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.

评论 #10064539 未加载

walkingolof将近 10 年前

"There are only two kinds of languages: the ones people complain about and the ones nobody uses". -Bjarne

swah将近 10 年前

Another way to look at it: the ones that can write that software are still chosing C/C++. The ones who would like to use Haskell/Rust/Java are discussing online.. :)

sklogic将近 10 年前

C still got a right to exist even in the very sensitive mission-critical environments, as long as MISRA requirements are followed (and, the good thing is that they can be automatically enforced).

评论 #10059572 未加载

w8rbt将近 10 年前

Secure software can be written in C or C++ (they are two different languages BTW). For example, OpenBSD and OpenSSH. Both are written in C and both have very good security records.

评论 #10059567 未加载

tempodox将近 10 年前

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 me anything other than C would be “too slow”.C is unbeatable as long as riding rodeo on your raw CPU is all you could ever want. But software has evolved, mankind's dependency on software has evolved, and so have our expectations & standards. It's time to learn the lesson and move on.

评论 #10059738 未加载

评论 #10060222 未加载

评论 #10059652 未加载

AnimalMuppet将近 10 年前

The article claims that the problem with Flash is not so much Flash itself, but that it's written in C/C++. It "proves" the point by listing a bunch of high-profile exploits in various other systems, then repeats the claim that C/C++ is the problem, and advocates abandoning C/C++.That's... not exactly proof. It's barely even evidence.Yes, you can argue "all these programs have all these flaws, and all are written in C/C++". And that's true. They are written in C/C++, and they have these flaws.Now let's look at the programs that do the same kinds of things, and are as widely used, and are not written in C/C++, and compare the number of exploits... oh, you don't have a handy list of equivalent programs to compare? Go work on that; I'll wait.The fundamental problem is that these programs are trying to safely handle hostile input, with attackers having essentially infinite time to experiment and craft attacks, including attacks that the authors didn't know that they needed to defend against at the time the code and/or the spec were written.Would the whole world be safer if everything were at least written in Java? Yes, it might be safer, but not safe. And it would take more resources, and often take longer to start up. And it would be vulnerable to bugs in the design and implementation of the JVM, which would become a single point of failure for a lot of software. That world would, perhaps, be somewhat safer, but it wouldn't be the security paradise that the article envisions.Not everyone is a fool who doesn't use the tools you think are best...

vu3rdd将近 10 年前

I think a lot of comments in this thread are too harsh. I am a C programmer myself and see the value of it in embedded systems, operating system kernels etc.While it is possible to write correct programs in C and C++ (which are very different languages, but usually mentioned together because of their names and history), it is too easy to make mistakes that are not caught by the compiler. It is easier to be sloppy in C than in say, Go or Rust. I have seen this in my own code and also in others' code.C is not the only way to write system programs. Oberon, Inferno are good examples of OS environments written in safer languages.But I agree that some of the disadvantages of C are also its advantages.The author of the blog post has more followup posts:<pre><code> http://trevorjim.com/why-safe-languages-are-the-best-way-to-achieve-memory-safety/ http://trevorjim.com/an-unsafe-legacy/ http://trevorjim.com/unsafe-at-any-speed/ </code></pre> [edit: fix typos, rephrase a few sentences, fix links]

carlosrg将近 10 年前

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.

评论 #10064544 未加载

sdf45将近 10 年前

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.

评论 #10059698 未加载

notacoward将近 10 年前

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

p0nce将近 10 年前

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.

评论 #10059959 未加载

eatonphil将近 10 年前

I'm confused when the author says the DOM is garbage collected only in IE/Blink. How is DOM memory managed elsewhere? At first guess, I thought the JavaScript runtime (which surely always uses garbage collection) would manage the DOM, but I'm guessing that's not actually the case. Who is typically in charge of memory management at that layer?

评论 #10060531 未加载

planteen将近 10 年前

Is there even an operating system not written in asm/C/C++ to run these "secure" non-C/C++ applications?

评论 #10060535 未加载

J2Alpha将近 10 年前

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.

评论 #10059665 未加载

stef13013将近 10 年前

If it's a joke it is quite good.Your post is full of memory leaks, can you rewrite it with a better language... Please.

cranklin将近 10 年前

garbage collection makes not a language safe

just4once将近 10 年前

Absurdly absurd ideas and ramblings. I suppose we can write our "safe languages" in "safe languages" then we'll never have need of really programming anything ourselves. We can simply pat together what ever is "safe" for us to do in our little play sandbox and act like we're adults who understand the problems faced when programming in "real" languages.This would be similar to replacing all automobiles with stuffed animals because, who in the world ever heard of stuffed animals getting into pile-up wreaks on the freeway and causing death misery and misfortune.

评论 #10059458 未加载

justwannasing将近 10 年前

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!"