4 ms·

So everything is unsafe by default, until you turn it on. Great...

pizlonator 2y ago
Weird this got downvoted since this is a big deal. The default matters. So long as the language makes it easy to write unsafe code, people will do it and there will be security bugs.
- blastonico 2y ago
  There will always be security bugs. Why do you think otherwise?
  - pizlonator 2y ago
    Yes but the point of safe languages is to eliminate the memory safety security bugs, which tend to be the worst and the most common. An unsafe-by-default language that has some safety features isn't enough to fix memory safety.
    - deleted 2y ago
      [deleted]
    - uecker 2y ago
      I don't they are the worst (often hard or impossible to exploit) and also not the most common according to: https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php (despite likely easy to find). Memory safety is something which can be solved though, which is what memory safe languages do. Of course, Rust is only an incremental improvement because of unsafe.
      - steveklabnik 2y ago
        The claim was scoped to the organizations that made the claim: Mozilla, Google, and Microsoft independently claimed that around 70% of their security issues were memory safety related, not that every CVE ever filed was that weighted towards one vulnerability class.
  - 29athrowaway 2y ago
    There are bad ideas with known consequences. We know what happens if you aim at your foot with a shotgun and then fire, for example. Unless you are doing something obscure like testing shotgun-proof footwear, it is a good idea to have an automated system tell you: "ERROR: You are shooting your foot, do not aim at your foot with a shotgun and fire on line 123". The C and C++ philosophy starts with the premise "programmers know best and will never aim a shotgun at their foot and then fire, that makes no sense haha, why are you talking to me about that? you are silly!". Yet, there are millions of people getting shot in the foot every year and it took a new language to demonstrate that the entire class of nonsense can be prevented.
    - JohnFen 2y ago
      > The C and C++ philosophy starts with the premise "programmers know best and will never aim a shotgun at their foot and then fire That's absolutely not the C/C++ philosophy. The C philosophy (I lost track of whatever the C++ philosophy is supposed to be several versions back) is that it's a mid-level language and lets you have pretty low-level access to the machine. With that comes the need for great caution, much like working in assembly. It's not premised on the idea that programmers are infallible at all, but on the idea that code-checking and correctness is to be done through process rather than the language itself.
      - vacuity 2y ago
        It isn't what is explicitly touted as standard, but it is what many developers have culturally established.
      - eacnamn 2y ago
        >That's absolutely not the C/C++ philosophy while it is not explicitly written out like this anymore, the standard charter used to say > Trust the programmer. > Don't prevent the programmer from doing what needs to be done. for 30 something years, which sounds similar to what the other poster said. The current charter[1] only says "Allow programming freedom" which I'd still interpret to mean something similar. 1: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3280.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3280.htm (edited due to formatting messups)
- 29athrowaway 2y ago
  Safety should be opt-out not opt-in. But this would break backwards compatibility and the C++people do not want that.
  - pizlonator 2y ago
    Fil-C/C++ is backwards compatible and has mandatory safety.
- 112233 2y ago
  Usability trumps safety every day. You can upgrade your compiler to version A. It produces safe code. It also produces 500kB of error messages for each of your source files. You will not ship any new builds until you fix all of them. Or you can pick version B. It compiles all your code with only few errors. It also supports opting-in to multiple safety features. If your salary depends on your software project, which will you pick?
  - croes 2y ago
    > Usability trumps safety every day That‘s the reason for all the problems in the first place.
- kreetx 2y ago
  I think the reason is that you don't want existing codebases to start erroring with the default setting.
quotemstr 2y ago
Yes, but there's hope. Making safety opt-in is a necessary prerequisite of backwards compatibility. Enforcing the use of safety annotations, however, is something that linters can enforce, and every major C++ codebase uses one form of another of supererogatory checking. By enforcing safety via linter, we've transitioned a robustness problem to an ergonomic one. Specifying "safe" over and over is hideous, aesthetically. I think C++ needs a broader "resyntaxing" --- something like what Elixer is to Erlang and Reason is to OCaml. Such a resyntaxing wouldn't change language semantics, but it would allow us to adopt new defaults --- ones that benefit from decades of hindsight. A C++ Elixer wouldn't only mark functions safe by default, but would probably make variables const by default too. And it would be 100% compatible with today's C++, since it would be the same language, merely spelled differently.

Weird this got downvoted since this is a big deal. The default matters. So long as the language makes it easy to write unsafe code, people will do it and there will be security bugs.

blastonico 2y ago
There will always be security bugs. Why do you think otherwise?
- pizlonator 2y ago
  Yes but the point of safe languages is to eliminate the memory safety security bugs, which tend to be the worst and the most common. An unsafe-by-default language that has some safety features isn't enough to fix memory safety.
  - deleted 2y ago
    [deleted]
  - uecker 2y ago
    I don't they are the worst (often hard or impossible to exploit) and also not the most common according to: https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php (despite likely easy to find). Memory safety is something which can be solved though, which is what memory safe languages do. Of course, Rust is only an incremental improvement because of unsafe.
    - steveklabnik 2y ago
      The claim was scoped to the organizations that made the claim: Mozilla, Google, and Microsoft independently claimed that around 70% of their security issues were memory safety related, not that every CVE ever filed was that weighted towards one vulnerability class.
- 29athrowaway 2y ago
  There are bad ideas with known consequences. We know what happens if you aim at your foot with a shotgun and then fire, for example. Unless you are doing something obscure like testing shotgun-proof footwear, it is a good idea to have an automated system tell you: "ERROR: You are shooting your foot, do not aim at your foot with a shotgun and fire on line 123". The C and C++ philosophy starts with the premise "programmers know best and will never aim a shotgun at their foot and then fire, that makes no sense haha, why are you talking to me about that? you are silly!". Yet, there are millions of people getting shot in the foot every year and it took a new language to demonstrate that the entire class of nonsense can be prevented.
  - JohnFen 2y ago
    > The C and C++ philosophy starts with the premise "programmers know best and will never aim a shotgun at their foot and then fire That's absolutely not the C/C++ philosophy. The C philosophy (I lost track of whatever the C++ philosophy is supposed to be several versions back) is that it's a mid-level language and lets you have pretty low-level access to the machine. With that comes the need for great caution, much like working in assembly. It's not premised on the idea that programmers are infallible at all, but on the idea that code-checking and correctness is to be done through process rather than the language itself.
    - vacuity 2y ago
      It isn't what is explicitly touted as standard, but it is what many developers have culturally established.
    - eacnamn 2y ago
      >That's absolutely not the C/C++ philosophy while it is not explicitly written out like this anymore, the standard charter used to say > Trust the programmer. > Don't prevent the programmer from doing what needs to be done. for 30 something years, which sounds similar to what the other poster said. The current charter[1] only says "Allow programming freedom" which I'd still interpret to mean something similar. 1: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3280.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3280.htm (edited due to formatting messups)
29athrowaway 2y ago
Safety should be opt-out not opt-in. But this would break backwards compatibility and the C++people do not want that.
- pizlonator 2y ago
  Fil-C/C++ is backwards compatible and has mandatory safety.
112233 2y ago
Usability trumps safety every day. You can upgrade your compiler to version A. It produces safe code. It also produces 500kB of error messages for each of your source files. You will not ship any new builds until you fix all of them. Or you can pick version B. It compiles all your code with only few errors. It also supports opting-in to multiple safety features. If your salary depends on your software project, which will you pick?
- croes 2y ago
  > Usability trumps safety every day That‘s the reason for all the problems in the first place.
kreetx 2y ago
I think the reason is that you don't want existing codebases to start erroring with the default setting.

quotemstr 2y ago

Yes, but there's hope. Making safety opt-in is a necessary prerequisite of backwards compatibility. Enforcing the use of safety annotations, however, is something that linters can enforce, and every major C++ codebase uses one form of another of supererogatory checking. By enforcing safety via linter, we've transitioned a robustness problem to an ergonomic one. Specifying "safe" over and over is hideous, aesthetically. I think C++ needs a broader "resyntaxing" --- something like what Elixer is to Erlang and Reason is to OCaml. Such a resyntaxing wouldn't change language semantics, but it would allow us to adopt new defaults --- ones that benefit from decades of hindsight. A C++ Elixer wouldn't only mark functions safe by default, but would probably make variables const by default too. And it would be 100% compatible with today's C++, since it would be the same language, merely spelled differently.