7 ms·

Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the w

Or you can flip it around and ask why there isn't a body in the C and C++ community funding tangible advancements in the security and safety problem space the way the Python Foundation and Rust Foundation are.

nindalf 3y ago
I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article. Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.
- cesarb 3y ago
  > That's why the author only suggests non-breaking changes in this article. One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).
  - jcelerier 3y ago
    It's ok if the current behaviour is changed into a compiler error
    - cesarb 3y ago
      I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)
    - saghm 3y ago
      That feels imprecise to the point of rendering the entire conversation useless. If every major C++ compiler shipped a copy of `rustc` renamed to `g++` or `clang++` or whatever, that would also make every breaking change a compiler error, but I don't think that's what anybody is talking about here.
      - Kranar 3y ago
        On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.
        PH95VuimJjqBqy 3y ago
        that's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++. 2nd and 3rd order thinking is a thing.
        Kranar 3y ago
        If a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++. Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.
        PH95VuimJjqBqy 3y ago
        If you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.
        Kranar 3y ago
        Too late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't. They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.
    - tovej 3y ago
      The example given here is a different interpretation of a statement. The source would stay the same for correct and incorrect use,there is no way for the compiler to catch this and send an error message.
      - Kranar 3y ago
        It's certainly possible to make an expression of the form "bool > bool" a compiler error and require that developers rewrite it as "x && !y"
- humanrebar 3y ago
  > I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The standards document isn't the same as a C++ implementation. The implementations are actually behind the standards, at least given current contribution levels. There are relatively few people making significant contributions to C and C++ in compilers. Funding for middle and backend features to compilers are a lot easier to justify and fund because it looks like more straightforward optimization payoffs. A lot of the effort put into C++ implementation work goes to keeping up with the pile of features added to the C and C++ standards every three years or so.
- soulbadguy 3y ago
  This : > So funding isn't the issue. does not follow from : > There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. The people working on the C++ committee are mostly working on their own time. Specific project directly funded by companies are actually quite rare. And those mostly focus on companies very immediate needs. If someone wanted to commit let's say 25$ million over 5 years, i am sure that both C++ standards and the major implementations would make large jump in term of safety. > The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. Yes C++ and its committee have very strong commitment to backward compatibility. However, that's not the reason for not wanting to make C++ memory safe : from what i understand, the committee decided that the tradeoff are not worth the gain, and as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice. > That's why the author only suggests non-breaking changes in this article. Just to repeat my point here: no, Hurb is suggesting non-breaking changes because of the aforementioned commitment to back-compat. Even if breaking changes were to be introduces, they would most likely NOT be to make C++ a memory safe language whole sale
  - nindalf 3y ago
    > as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice. This is the main contention. For those who believe in the technical leadership of the committee, this feels like a reasonable way forward. I'm sure in theory these issues can be tackled, it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub https://research.swtch.com/ub). In that context, where you can change the APIs but you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety. I think we'll find out in 5 years if their optimism was well founded.
    - 3y ago
- pizlonator 3y ago
  But they do break stuff. I think the commitment is more that you can’t do anything to the language that would lead to some compiler hacker who also serves on the committee to have to remove their pet optimization, regardless of whether that optimization is worth much (or anything). Goals and messaging matter. I like that the Rust community aims for safety as a P1 goal. C doesn’t, so C doesn’t get it.

nindalf 3y ago

I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article. Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.

cesarb 3y ago
> That's why the author only suggests non-breaking changes in this article. One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).
- jcelerier 3y ago
  It's ok if the current behaviour is changed into a compiler error
  - cesarb 3y ago
    I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)
  - saghm 3y ago
    That feels imprecise to the point of rendering the entire conversation useless. If every major C++ compiler shipped a copy of `rustc` renamed to `g++` or `clang++` or whatever, that would also make every breaking change a compiler error, but I don't think that's what anybody is talking about here.
    - Kranar 3y ago
      On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.
      - PH95VuimJjqBqy 3y ago
        that's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++. 2nd and 3rd order thinking is a thing.
        Kranar 3y ago
        If a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++. Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.
        PH95VuimJjqBqy 3y ago
        If you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.
        Kranar 3y ago
        Too late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't. They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.
  - tovej 3y ago
    The example given here is a different interpretation of a statement. The source would stay the same for correct and incorrect use,there is no way for the compiler to catch this and send an error message.
    - Kranar 3y ago
      It's certainly possible to make an expression of the form "bool > bool" a compiler error and require that developers rewrite it as "x && !y"
humanrebar 3y ago
> I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The standards document isn't the same as a C++ implementation. The implementations are actually behind the standards, at least given current contribution levels. There are relatively few people making significant contributions to C and C++ in compilers. Funding for middle and backend features to compilers are a lot easier to justify and fund because it looks like more straightforward optimization payoffs. A lot of the effort put into C++ implementation work goes to keeping up with the pile of features added to the C and C++ standards every three years or so.
soulbadguy 3y ago
This : > So funding isn't the issue. does not follow from : > There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++. The people working on the C++ committee are mostly working on their own time. Specific project directly funded by companies are actually quite rare. And those mostly focus on companies very immediate needs. If someone wanted to commit let's say 25$ million over 5 years, i am sure that both C++ standards and the major implementations would make large jump in term of safety. > The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. Yes C++ and its committee have very strong commitment to backward compatibility. However, that's not the reason for not wanting to make C++ memory safe : from what i understand, the committee decided that the tradeoff are not worth the gain, and as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice. > That's why the author only suggests non-breaking changes in this article. Just to repeat my point here: no, Hurb is suggesting non-breaking changes because of the aforementioned commitment to back-compat. Even if breaking changes were to be introduces, they would most likely NOT be to make C++ a memory safe language whole sale
- nindalf 3y ago
  > as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice. This is the main contention. For those who believe in the technical leadership of the committee, this feels like a reasonable way forward. I'm sure in theory these issues can be tackled, it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub https://research.swtch.com/ub). In that context, where you can change the APIs but you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety. I think we'll find out in 5 years if their optimism was well founded.
  - 3y ago
pizlonator 3y ago
But they do break stuff. I think the commitment is more that you can’t do anything to the language that would lead to some compiler hacker who also serves on the committee to have to remove their pet optimization, regardless of whether that optimization is worth much (or anything). Goals and messaging matter. I like that the Rust community aims for safety as a P1 goal. C doesn’t, so C doesn’t get it.