Mozilla has run a very large-scale C++ project for many years, with an elite team of developers. Mozilla makes extensive use of enormous test suites, static checkers, Valgrind, ASAN, TSAN, etc. Mozilla created Rust because we concluded C++ was not reliable enough or secure enough for large-scale multithreaded applications.
No, Ada in practice doesn't have memory safety or thread safety. For high-assurance stuff like avionics you can avoid those problems with theorem proving or by sticking to an extremely limit language subset that e.g. forbids dynamic heap allocations... but that is not practical for large applications.
Many Web sites have memory leaks. Some Firefox process bloating overnight is a lot more likely to be a problem with a Web site running in that process than with Firefox itself.
There are some things that can be done in the browser to help, but ultimately Web site leaks are not fixable by the browser itself.
I agree that C was a good language in the 1980s, but it doesn't matter now what was the best language in the 1980s. People making language choices today need to consider what is their most suitable language today, and unfortunately the baggage from C's history is still holding it back.
I'll be happy to revise my opinion of C when your superior implementation is available.
Implementation quality is highly relevant to the quality of the language. Anyway, in C's case very few of the issues are actually fixable by improving the implementation, at least without breaking most existing C code.
> No offence but I can tell you are not a C programmer.
Been programming in C since the 1980s. 20 years industrial C++ experience, most of it working on Gecko which is a multimillion-line C++ project. PhD in computer science from Carnegie Mellon. Mozilla Distinguished Engineer.
> In C with a few years of experience and study you can know everything there is to know.
Well I guess I'm good to go then.
> There are no obscure undefined behaviours,
Really, so when these MIT researchers write "Unfortunately, the rules for what is undefined behavior are subtle" and "tricky", you think they're just idiots? https://people.csail.mit.edu/n...
Unions impose no relationship between the variants and the tag, and are therefore bug-prone.
Boost is a C++ library. Are you confused?
> Any "replacement" for C is going to have to work in environments with memory measured in bytes.
I agree. I use Rust as much as possible now, and it can target 8-bit microcontrollers, so we're good. I don't want C# or Java (although they're fine for many use-cases, as is Go).
C++ is certainly better for safety in some ways, if only because you have ergonomic dynamically-sized arrays and smart pointers. However C++ has even more crazy undefined behaviors, is vastly more complex, and the safety benefits of smart pointers are overrated --- it's still very easy to have use-after-free bugs in "modern C++", and some of the new features are actually making things worse. See https://github.com/isocpp/CppC... for example.
This is like saying that there's nothing wrong with a car that has dodgy brakes and no seatbelts or mirrors. After all, it's still possible to drive safely if you try hard enough.
Properly training developers and using tools like Valgrind/ASAN etc does not prevent the critical security bugs that are prevented by safe languages. I've worked with elite C/C++ developers at Mozilla and Google, who use those tools and a lot more, yet such bugs are regularly discovered in shipping code. Here's another take on this: https://lwn.net/Articles/73545...
OWASP is about vulnerabilities in Web applications, practically none of which are written in C or C++. If they were, then OWASP would include bugs like use-after-free and buffer overflow.
A lot of issues with Web application security are because of the dynamically typed languages used, which are a whole different issue. It's certainly not the case that every language other than C is great for security.
If the bridge can be built for about the same cost as the 4x4, why not build the bridge? As a user I'd certainly rather have the bridge.
For a lot of what C is used for, security and reliability are important, and C's (and C++'s) deficiencies are critical by any definition. See http://robert.ocallahan.org/20... for more of my thoughts on that.
When security and reliability truly don't matter, C's deficiencies are only critical if you care about wasting time and money developing in a language without any modern productivity features.
(Note that developers tend to underestimate the importance of security and reliability of their code. If you create a library and release it, you never know when someone's going to use it on untrusted input or as a component of an important system.)
The code of conduct doesn't prohibit disagreement.
Anyway you don't need to deal with the CoC just because you use Rust. In fact, you're free to form your own "Rust for Assholes" forum. That might actually be a useful service.
C++ is an insane language that no-one truly understands.
Here's an example: according to the Standard, you are not allowed to call push_back() on a vector>. Can you explain why? I'll post the answer as a separate comment on this article.
For kernels you want predictable latencies, robust OOM handling, and synchronous and predictable memory reclamation. You don't want the complexity of a modern concurrent GC, and you don't want the throughput/memory overhead penalties of a naive GC.
People have tried to write kernels in GC languages before and it hasn't been adopted. See SPIN (Modula-3). Microsoft invested a ton of effort writing Windows code in C# for Vista that never shipped because they couldn't make it robust in low-memory conditions. See also https://www.cs.virginia.edu/~b....
Slashdot Mirror
Mozilla has run a very large-scale C++ project for many years, with an elite team of developers. Mozilla makes extensive use of enormous test suites, static checkers, Valgrind, ASAN, TSAN, etc. Mozilla created Rust because we concluded C++ was not reliable enough or secure enough for large-scale multithreaded applications.
No, Ada in practice doesn't have memory safety or thread safety. For high-assurance stuff like avionics you can avoid those problems with theorem proving or by sticking to an extremely limit language subset that e.g. forbids dynamic heap allocations ... but that is not practical for large applications.
If you can figure out which site it is, and it's reproducible, it would be worth filing a bug in Mozilla's Bugzilla.
Google gets something in return: the search traffic generated by Firefox users searching through the Firefox UI.
Noscript has been available for Firefox 57 for a few days now. Not sure about Lastpass.
Many Web sites have memory leaks. Some Firefox process bloating overnight is a lot more likely to be a problem with a Web site running in that process than with Firefox itself.
There are some things that can be done in the browser to help, but ultimately Web site leaks are not fixable by the browser itself.
Having zero extensions installed is by far the most common usage scenario. Mozilla has measured this.
Firefox-57-compatible Noscript was released five days ago. https://www.bleepingcomputer.c...
The reload button is in the "customize" window. It's three clicks (and a drag) to put it wherever you want.
Do you have evidence this is a "paid ad", or did you just make that claim up?
Good thing those are all still there in 57 then. (Except maybe live bookmarks; I'm not sure about that.)
Slashdot mangled my comment and my attempt to fix it was unclear.
The problem is that technically you can't call push_back on a vector < map < T, unique_ptr < U > > >
I agree that C was a good language in the 1980s, but it doesn't matter now what was the best language in the 1980s. People making language choices today need to consider what is their most suitable language today, and unfortunately the baggage from C's history is still holding it back.
It's funny you mention strncpy. That is also broken! See https://randomascii.wordpress.... for example.
I'll be happy to revise my opinion of C when your superior implementation is available.
Implementation quality is highly relevant to the quality of the language. Anyway, in C's case very few of the issues are actually fixable by improving the implementation, at least without breaking most existing C code.
> No offence but I can tell you are not a C programmer.
Been programming in C since the 1980s. 20 years industrial C++ experience, most of it working on Gecko which is a multimillion-line C++ project. PhD in computer science from Carnegie Mellon. Mozilla Distinguished Engineer.
> In C with a few years of experience and study you can know everything there is to know.
Well I guess I'm good to go then.
> There are no obscure undefined behaviours,
Really, so when these MIT researchers write "Unfortunately, the rules for what is undefined behavior are subtle" and "tricky", you think they're just idiots?
https://people.csail.mit.edu/n...
Unions impose no relationship between the variants and the tag, and are therefore bug-prone.
Boost is a C++ library. Are you confused?
> Any "replacement" for C is going to have to work in environments with memory measured in bytes.
I agree. I use Rust as much as possible now, and it can target 8-bit microcontrollers, so we're good. I don't want C# or Java (although they're fine for many use-cases, as is Go).
C++ is certainly better for safety in some ways, if only because you have ergonomic dynamically-sized arrays and smart pointers. However C++ has even more crazy undefined behaviors, is vastly more complex, and the safety benefits of smart pointers are overrated --- it's still very easy to have use-after-free bugs in "modern C++", and some of the new features are actually making things worse. See https://github.com/isocpp/CppC... for example.
> How is that C's fault?
This is like saying that there's nothing wrong with a car that has dodgy brakes and no seatbelts or mirrors. After all, it's still possible to drive safely if you try hard enough.
Properly training developers and using tools like Valgrind/ASAN etc does not prevent the critical security bugs that are prevented by safe languages. I've worked with elite C/C++ developers at Mozilla and Google, who use those tools and a lot more, yet such bugs are regularly discovered in shipping code. Here's another take on this: https://lwn.net/Articles/73545...
OWASP is about vulnerabilities in Web applications, practically none of which are written in C or C++. If they were, then OWASP would include bugs like use-after-free and buffer overflow.
A lot of issues with Web application security are because of the dynamically typed languages used, which are a whole different issue. It's certainly not the case that every language other than C is great for security.
If the bridge can be built for about the same cost as the 4x4, why not build the bridge? As a user I'd certainly rather have the bridge.
For a lot of what C is used for, security and reliability are important, and C's (and C++'s) deficiencies are critical by any definition. See http://robert.ocallahan.org/20... for more of my thoughts on that.
When security and reliability truly don't matter, C's deficiencies are only critical if you care about wasting time and money developing in a language without any modern productivity features.
(Note that developers tend to underestimate the importance of security and reliability of their code. If you create a library and release it, you never know when someone's going to use it on untrusted input or as a component of an important system.)
The code of conduct doesn't prohibit disagreement.
Anyway you don't need to deal with the CoC just because you use Rust. In fact, you're free to form your own "Rust for Assholes" forum. That might actually be a useful service.
Sounds like Rust is for you then.
The answer is here: https://bugs.chromium.org/p/ch...
Er, that got mangled. It's a map < T unique_ptr < U > >
C++ is an insane language that no-one truly understands.
Here's an example: according to the Standard, you are not allowed to call push_back() on a vector>. Can you explain why? I'll post the answer as a separate comment on this article.
Yeah, but better languages eliminate whole classes of security bugs that plague C programs, including the bugs that hit dnsmasq.
This is one of the lamest defense of C: "You can't prevent all bugs, so why bother trying to prevent any".
For kernels you want predictable latencies, robust OOM handling, and synchronous and predictable memory reclamation. You don't want the complexity of a modern concurrent GC, and you don't want the throughput/memory overhead penalties of a naive GC.
People have tried to write kernels in GC languages before and it hasn't been adopted. See SPIN (Modula-3). Microsoft invested a ton of effort writing Windows code in C# for Vista that never shipped because they couldn't make it robust in low-memory conditions. See also https://www.cs.virginia.edu/~b....