Of course not, but why have coding problems in addition to design problems? If you want to get your project done you always want fewer problems, not more problems.
No one's arguing a language solves your algorithm problems. But why have security problems in addition to your algorithm problems? As discussed in the presentation, the flaws in these applications were all the "usual suspects". When you keep seeing the same problems again and again it's time to use better tools, including better languages.
There are many vulnerabilities in software in every language.
Yes, which is why it's important for the language to mitigate that as much as possible. Your mistake while doing something as trivial as a forum post demonstrates the fallibility of the programmer.
programs written in Rust may very well have more serious vulnerabilities than any other language
Is it? Let's have a look at a security analysis of applications written in C on FreeRTOS. It seems like they're riddled with flaws. Saying "just write better code" lacks real world perspective.
Again, your convenience just isn't. Why wouldn't function_that_uses_pointer() protect itself by doing the pointer check internally? That way function_that_uses_pointer() wouldn't have to worry about someone remembering to do the check every time it is called and you could write:
result = function_that_could_return_a_null_pointer();
function_that_uses_pointer(result);
This is naive at best. It's one line different doing the assignment outside of the if test, and you believe this is some kind of grand convenience? Assignment inside an if test is not worth the problems it introduces.
Why not simply use a language that avoids the problem in the first place? In Pascal, for example, you can't do an assignment inside an if test. It's a wiser design choice.
The fact that the Joint Strike Fighter's coding standards are based on MISRA C is not a good advertisement for it. The JSF's software still doesn't work right and they've been working on it for 20 years. Following MISRA C didn't avoid those problems.
The little button to add a new tab is now invisible until you mouse over it.
I don't see that behavior on macOS or Windows 10 with Firefox 62 or 63 beta using any of the default themes. The "+" button is always visible. Which OS and theme are you using?
Reread the thread. The claim was that C\C++ is somehow special because "you can write entire operating systems in it". In reality many languages can achieve the same things as C\C++, such as operating system development. We're comparing languages, not operating systems.
Slashdot Mirror
Of course not, but why have coding problems in addition to design problems? If you want to get your project done you always want fewer problems, not more problems.
No one's arguing a language solves your algorithm problems. But why have security problems in addition to your algorithm problems? As discussed in the presentation, the flaws in these applications were all the "usual suspects". When you keep seeing the same problems again and again it's time to use better tools, including better languages.
How would you write this "copy each character" in Pascal?
Like this: myString := myOtherString;
C's string handling is nothing to take pride in.
By habitually putting the constant on the left side, I'd get a compile error if I accidentally typed = instead of ==.
Pascal doesn't have the problem in the first place.
Slashdot ate the because
No, you just got it wrong.
There are many vulnerabilities in software in every language.
Yes, which is why it's important for the language to mitigate that as much as possible. Your mistake while doing something as trivial as a forum post demonstrates the fallibility of the programmer.
programs written in Rust may very well have more serious vulnerabilities than any other language
Prove it.
Your quiche-eating opinion isn't going to change C
Of course it isn't. That's why you're better off using a language that avoids C's problems in the first place. Maybe reread the thread.
Friggin Slashdot ate my post
Whoops. Mistakes like that happening are why allowing assignment in an if test is a bad idea. Too easy to get wrong.
if ( thegamma = get_gamma() ) {
Wow, man. So the alternative is an extra line:
thegamma = get_gamma();
if (thegamma) {
Hardly seems inconvenient. You're arguing for a misfeature.
Because
Your post didn't work very well. There was no because.
C is for systems programmers who already need to be aware that they can't just make assumptions
Then why are there so many vulnerabilities in C applications? Seems like there are assumptions aplenty.
C is already safe
Is it? Let's have a look at a security analysis of applications written in C on FreeRTOS. It seems like they're riddled with flaws. Saying "just write better code" lacks real world perspective.
Again, your convenience just isn't. Why wouldn't function_that_uses_pointer() protect itself by doing the pointer check internally? That way function_that_uses_pointer() wouldn't have to worry about someone remembering to do the check every time it is called and you could write:
result = function_that_could_return_a_null_pointer();
function_that_uses_pointer(result);
Or even:
function_that_uses_pointer(function_that_could_return_a_null_pointer());
All the "convenience" did for you was to structure your program poorly. And worse, it made you think the bad structure was a good idea.
(perhaps you think P-code when you write Pascal, good for you!)
You're a little out of date. You have some reading to do.
No, it doesn't create problems for Pascal programmers because Pascal doesn't have this problem. Maybe reread the thread.
Whatever floats your boat. Try not to get any on the keyboard.
This is naive at best. It's one line different doing the assignment outside of the if test, and you believe this is some kind of grand convenience? Assignment inside an if test is not worth the problems it introduces.
So.. the answer is "never". Pretty lame, kid.
Because its convenient sometimes
When?
everything wrong in Pascal
Like what?
Why not simply use a language that avoids the problem in the first place? In Pascal, for example, you can't do an assignment inside an if test. It's a wiser design choice.
The fact that the Joint Strike Fighter's coding standards are based on MISRA C is not a good advertisement for it. The JSF's software still doesn't work right and they've been working on it for 20 years. Following MISRA C didn't avoid those problems.
You can use the built-in Reader View for a lot of pages, but it's not available for all pages. It depends on the page structure.
The little button to add a new tab is now invisible until you mouse over it.
I don't see that behavior on macOS or Windows 10 with Firefox 62 or 63 beta using any of the default themes. The "+" button is always visible. Which OS and theme are you using?
Nope. All you're doing is arguing yourself into a niche. Like I say, read the papers on Tock. It already out delivers FreeRTOS.
Standard Pascal strings were limited to 255 ASCII-7 characters.
But this hasn't been the case for decades. Try FreePascal or the community edition of Delphi to see the current state of Object Pascal.
I'm offering the chance for you to show me some.
Gosh, I'm ever so grateful. If you want a Rust-based operating system on small hardware, try Tock. Read some papers on it.
Reread the thread. The claim was that C\C++ is somehow special because "you can write entire operating systems in it". In reality many languages can achieve the same things as C\C++, such as operating system development. We're comparing languages, not operating systems.
Don't worry. There's a Rust Verification working group aimed at developing formal verification methods for Rust. See also RustBelt.
OCaml originally, but Rust is now self-hosting.