4 ms·

It would make most security bugs caused by unsafe by default memory management which do account for a high percentage of security bugs, but logic bugs also caus

by Havvy 12y ago

It would make most security bugs caused by unsafe by default memory management which do account for a high percentage of security bugs, but logic bugs also cause security issues. See for instance SQL Injection attacks.

tormeh 12y ago
Yes, but I can't help but imagine how an OS written in Rust would look. Probably a lot better than what we have today. A combination of Rust and D would probably be capable of doing everything C and C++ can, and much better.
- 72deluxe 12y ago
  Let the language wars commence! In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.
  - zxcdw 12y ago
    > In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?
    - 72deluxe 12y ago
      Yes, modern C++ is far safer than the old style or passing pointers all over the place and wondering who was deleting them (not that I ever did that - you could pass const pointers to stop others deleting them anyway; it was only a problem if you didn't obey const-correctness and make certain classes "container" classes). The addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. It's a difficult habit to break though! See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources". See std::move to force moving where it isn't clear that you're moving things. Further reading: http://en.cppreference.com/w/cpp/language/move_operator http://en.cppreference.com/w/cpp/language/move_operator http://stroustrup.com/C++11FAQ.html#default2 http://stroustrup.com/C++11FAQ.html#default2
      - pjmlp 12y ago
        The sad reality that I came to realize from this year's CppCon is that most C++ developers out there will just keep on writing pre-C++98 code, due to multiple reasons like style guides, company policy, old code bases and so on. Only greefield projects can benefit from modern C++ and there are very few out there. After reading the updated version of Effective C++, I doubt the average C++ developer will be able to deal with a mixed codebase of pre-C++98, C++98, C++03, C++11 and C++14.
        72deluxe 12y ago
        This is very true. I am writing new software for my dayjob but I am stuck with VC2010 on Windows. Despite having Xcode under Mac OS, I have to write old-fashioned C++ as VC2010 doesn't support anything new! But it helps to learn the new stuff and apply it within my own projects as best I can.
Dewie 12y ago
> , but logic bugs also cause security issues. See for instance SQL Injection attacks. Though it seems that some languages, or at least how they are used, are more disciplined when it comes to treating things like SQL queries/commands; that they don't treat them as plain text, and instead assign some kind of structure/typing to the query command. Or don't they? I don't really know how SQL injections are handled in such languages, but I do know that some like to be more principled when it comes to SQL queries/commands in the source code text; like using macros to ensure that an SQL query doesn't have a typo in it. Maybe that kind of practice extends to validating user input.
- mikeash 12y ago
  Strings are a big security hole that doesn't get nearly enough attention. Conceptually there are a ton of different string types. File names, path names, SQL query templates, SQL query strings, URLs, URL query parameters, command line arguments, full command lines, human-readable text.... Yet just about everything gloms them together into one "string" type. Even APIs that allow for structured construction of SQL queries tend to rely on the programmer not to put arbitrary data in the template bits. These really should all be completely separate types requiring conversion.
userbinator 12y ago
See for instance SQL Injection attacks. Or more recently and widely publicised, ShellShock.

by Havvy 12y ago

tormeh 12y ago

Yes, but I can't help but imagine how an OS written in Rust would look. Probably a lot better than what we have today. A combination of Rust and D would probably be capable of doing everything C and C++ can, and much better.

72deluxe 12y ago
Let the language wars commence! In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. As with ANY language, if you write it badly, bad things will happen. The language choice doesn't mean bug-free code.
- zxcdw 12y ago
  > In reality, there is nothing wrong with C++, particularly not modern C++ (since c++11) as the approaches laid out in Stroustrup's book discourage writing C++ in the old-fashioned "let's throw pointers around!" approach. So, in essence this would mean to many that Rusts safety focus happens too late for it to be a big enough benefit for having to give up the investment in modern C++? As in, memory safety is a solved problem with modern C++?
  - 72deluxe 12y ago
    Yes, modern C++ is far safer than the old style or passing pointers all over the place and wondering who was deleting them (not that I ever did that - you could pass const pointers to stop others deleting them anyway; it was only a problem if you didn't obey const-correctness and make certain classes "container" classes). The addition of move semantics and using references everywhere makes pointers unnecessary for the most part. You can use STL containers for putting your items into so shouldn't see raw "new" or "delete" operations in your own code very much; this is particularly true where you define your own move operators and move constructors. It's a difficult habit to break though! See Stroustrup's "The C++ Programming Language Fourth Edition" (the blue book) section 3.3.3 Resource Management and 3.2.1.2 "A Container", where in this early part of the book Stroustrup explicitly directs to 'avoid "naked" new and delete operations" and to "use resource handles and RAII to manage resources". See std::move to force moving where it isn't clear that you're moving things. Further reading: http://en.cppreference.com/w/cpp/language/move_operator http://en.cppreference.com/w/cpp/language/move_operator http://stroustrup.com/C++11FAQ.html#default2 http://stroustrup.com/C++11FAQ.html#default2
    - pjmlp 12y ago
      The sad reality that I came to realize from this year's CppCon is that most C++ developers out there will just keep on writing pre-C++98 code, due to multiple reasons like style guides, company policy, old code bases and so on. Only greefield projects can benefit from modern C++ and there are very few out there. After reading the updated version of Effective C++, I doubt the average C++ developer will be able to deal with a mixed codebase of pre-C++98, C++98, C++03, C++11 and C++14.
      - 72deluxe 12y ago
        This is very true. I am writing new software for my dayjob but I am stuck with VC2010 on Windows. Despite having Xcode under Mac OS, I have to write old-fashioned C++ as VC2010 doesn't support anything new! But it helps to learn the new stuff and apply it within my own projects as best I can.

Dewie 12y ago

> , but logic bugs also cause security issues. See for instance SQL Injection attacks. Though it seems that some languages, or at least how they are used, are more disciplined when it comes to treating things like SQL queries/commands; that they don't treat them as plain text, and instead assign some kind of structure/typing to the query command. Or don't they? I don't really know how SQL injections are handled in such languages, but I do know that some like to be more principled when it comes to SQL queries/commands in the source code text; like using macros to ensure that an SQL query doesn't have a typo in it. Maybe that kind of practice extends to validating user input.

mikeash 12y ago
Strings are a big security hole that doesn't get nearly enough attention. Conceptually there are a ton of different string types. File names, path names, SQL query templates, SQL query strings, URLs, URL query parameters, command line arguments, full command lines, human-readable text.... Yet just about everything gloms them together into one "string" type. Even APIs that allow for structured construction of SQL queries tend to rely on the programmer not to put arbitrary data in the template bits. These really should all be completely separate types requiring conversion.

userbinator 12y ago

See for instance SQL Injection attacks. Or more recently and widely publicised, ShellShock.