4 ms·

I appreciate the direct nod to security. But as written I doubt it's enough. The goal is to "enable" secure programming, and C already meets that goal since it

I appreciate the direct nod to security. But as written I doubt it's enough. The goal is to "enable" secure programming, and C already meets that goal since it is theoretically possible. The problem is that busy human developers are not good at being perfect. There are far more ways to get things wrong, and minor mistakes become far more serious problems in C and C++ compared to other languages. I do wish the group good luck!!

flohofwoe 2y ago
Even just the stated goal to 'eliminate or reduce' undefined, unspecified and implementation defined behaviour is worth a lot since it would eliminate a pretty big minefield of "unintended consequences" in modern compilers.
- jmclnx 2y ago
  I hope they follow that guideline, looks good to me. But being a cynic, in the past when I see good guidelines posted, it is not long before all the exact opposite happens and the guidelines are meaningless :(
- bdw5204 2y ago
  There's an easy way to eliminate unspecified behavior in C or C++: Have a compiler flag to always issue warnings for it and treat those warnings as errors. That doesn't require any language-level changes to implement.
  - throwawaymaths 2y ago
    Complete eradication should never be a goal though. There are extremely reasonable forms of undefined behavior that the compiler can use to optimize your code. It just has to be known that tripping those guardrails is undefined.
  - jcranmer 2y ago
    Considering that unspecified behavior includes whether or not you execute the LHS of a binary operator before the RHS, such a mode would not be very useful. Even assuming you meant undefined behavior instead of unspecified behavior, it's still not a particularly practical prospect, for you basically prohibit any use of pointers (or memory access in general) whatsoever.
  - bluGill 2y ago
    That isn't possible. Does "X / Y" divide by 0? Often the compiler has no way of knowing. Sure code can always check for Y == 0 - but if the programmer has knowledge the compiler doesn't that Y can never be 0 this if statement can needlessly slow down code (CPU branch mispredictions are costly). There are other places where we can prove that code is safe in most conditions but proving the exception never happens is equivalent to proving the halting problem.
    - CoastalCoder 2y ago
      Is there a term for predicates that are checked by static analysis when possible, but relegated to runtime checks when not?
      - account42 2y ago
        That's just any runtime check with an optimizing compiler - conditionals that the compiler can prove are always true / always false can get eliminated.
      - UncleMeat 2y ago
        Exhaustive runtime checks for all forms of UB are basically impossible. A data race is UB. Are you going to find a way to insert correct data race detection on all writes? Writing through an invalid pointer alias is UB. How are you going to detect when that happens at runtime? Sanitizers exist and do detect a subset of UB via runtime checks, but there is nothing resembling a system that can detect all UB. That would basically require an entire VM implementing the C-standard with a truly outrageous amount of runtime overhead.
        torstenvl 2y ago
        The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. Writing through an invalid pointer is perfectly definable. The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted, but that whether the write succeeds and what second- and third-order effects result from such a write are dependent on the environment, including operating system. Boom. Not undefined behavior. But still potentially dangerous behavior with unpredictable results. (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.)
bluGill 2y ago
We will see how this plays out. I'm not sure what options C has though, while remaining backward compatible. They removed gets (which cannot be used safely) in C11, but most things people don't like in C it is really hard to figure out how to make an alternative while still being C (that is compatible and looks like existing C) C++ is actively working on profiles, and if you enable the right profile many of the easy ways to be insecure are not longer possible. Or at least that is the goal only time will tell if they make it in, and then more time if they are both used and make a difference. However C++ developers have long said "No naked new/delete", data structures where the invariant (length...) is enforced - thus a profile can remove new/delete and the places where we now know the data structure invariant isn't enforced while still being a usable language. Because of the above anyone who is in C++ objects to phrases like "C and C++ or C/C++" - C++ is trying to leave C behind expect where compatibility with C is required.
- tialaramex 2y ago
  > C++ is trying to leave C behind expect where compatibility with C is required. What was it Dua Lipa sings? "If you're under him, you ain't getting over him". C is foundational to C++. Look at your miserable type system. Do you think anybody who designs type systems built that? No. This is the C type system, it's defective but it was easy to implement. Actually fixing C++ needs a ground-up rebuild, that's what you see (impressively) in Sean Baxter's work for example. I doubt it will make a real difference, but to his credit Sean looked at all the horrible problems and rolled up his sleeves and fixed them with a fairly radical set of required language and library changes, rather than kicking them under a rug and insisting it's all fine, just don't look under the rug.
- uecker 2y ago
  C can essentially do the same thing. I do not see why C++ would have a fundamental advantage here.
VyseofArcadia 2y ago
It's a social problem. People make mistakes, or are coerced into letting mistakes persist, because you have to get the features out. And if you stand your ground on security, management will find someone who won't. If software "engineers" were engineers who had the duty and authority to say "no, I won't build something unsafe" we'd have fewer problems. Not to say that improved tools isn't also a worthy goal, but why not attack the problem from all angles?
pyeri 2y ago
Those busy humans can always switch to rust or Java? Those ain't bad languages either. And let's face it, given its bare metal nature, there are always going to be limits on how "secure" you can make it in order to "protect" the developer from goofing up in C/C++.
ngneer 2y ago
I agree with almost all of your analysis. One has to be an excellent programmer to write secure code, doubly so in C. I disagree with your conclusion, though. To me, the above means that C FAILS to meet the goal of enabling secure programming. An analogy might be car safety. Yes, if we had perfect drivers we would not even need seatbelts, let alone airbags. But, I would definitely say that a car without these does not meet the goal of "enabling" safe driving merely because it is theoretically possible. https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/812069.pdf https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...

flohofwoe 2y ago

Even just the stated goal to 'eliminate or reduce' undefined, unspecified and implementation defined behaviour is worth a lot since it would eliminate a pretty big minefield of "unintended consequences" in modern compilers.

jmclnx 2y ago
I hope they follow that guideline, looks good to me. But being a cynic, in the past when I see good guidelines posted, it is not long before all the exact opposite happens and the guidelines are meaningless :(
bdw5204 2y ago
There's an easy way to eliminate unspecified behavior in C or C++: Have a compiler flag to always issue warnings for it and treat those warnings as errors. That doesn't require any language-level changes to implement.
- throwawaymaths 2y ago
  Complete eradication should never be a goal though. There are extremely reasonable forms of undefined behavior that the compiler can use to optimize your code. It just has to be known that tripping those guardrails is undefined.
- jcranmer 2y ago
  Considering that unspecified behavior includes whether or not you execute the LHS of a binary operator before the RHS, such a mode would not be very useful. Even assuming you meant undefined behavior instead of unspecified behavior, it's still not a particularly practical prospect, for you basically prohibit any use of pointers (or memory access in general) whatsoever.
- bluGill 2y ago
  That isn't possible. Does "X / Y" divide by 0? Often the compiler has no way of knowing. Sure code can always check for Y == 0 - but if the programmer has knowledge the compiler doesn't that Y can never be 0 this if statement can needlessly slow down code (CPU branch mispredictions are costly). There are other places where we can prove that code is safe in most conditions but proving the exception never happens is equivalent to proving the halting problem.
  - CoastalCoder 2y ago
    Is there a term for predicates that are checked by static analysis when possible, but relegated to runtime checks when not?
    - account42 2y ago
      That's just any runtime check with an optimizing compiler - conditionals that the compiler can prove are always true / always false can get eliminated.
    - UncleMeat 2y ago
      Exhaustive runtime checks for all forms of UB are basically impossible. A data race is UB. Are you going to find a way to insert correct data race detection on all writes? Writing through an invalid pointer alias is UB. How are you going to detect when that happens at runtime? Sanitizers exist and do detect a subset of UB via runtime checks, but there is nothing resembling a system that can detect all UB. That would basically require an entire VM implementing the C-standard with a truly outrageous amount of runtime overhead.
      - torstenvl 2y ago
        The problem is the conflation of at least three different working definitions of "undefined behavior." Strictly speaking, undefined behavior only means that the Standard does not impose a requirement. But what many people mean is that the ramifications are outside the scope of the language or are unpredictable. Writing through an invalid pointer is perfectly definable. The standard could easily specify solely that the write to the memory location indicated in the pointer will be attempted, but that whether the write succeeds and what second- and third-order effects result from such a write are dependent on the environment, including operating system. Boom. Not undefined behavior. But still potentially dangerous behavior with unpredictable results. (In my view, this is in fact what ANSI C requires for this type of "undefined behavior," but many others do not agree.)

bluGill 2y ago

We will see how this plays out. I'm not sure what options C has though, while remaining backward compatible. They removed gets (which cannot be used safely) in C11, but most things people don't like in C it is really hard to figure out how to make an alternative while still being C (that is compatible and looks like existing C) C++ is actively working on profiles, and if you enable the right profile many of the easy ways to be insecure are not longer possible. Or at least that is the goal only time will tell if they make it in, and then more time if they are both used and make a difference. However C++ developers have long said "No naked new/delete", data structures where the invariant (length...) is enforced - thus a profile can remove new/delete and the places where we now know the data structure invariant isn't enforced while still being a usable language. Because of the above anyone who is in C++ objects to phrases like "C and C++ or C/C++" - C++ is trying to leave C behind expect where compatibility with C is required.

tialaramex 2y ago
> C++ is trying to leave C behind expect where compatibility with C is required. What was it Dua Lipa sings? "If you're under him, you ain't getting over him". C is foundational to C++. Look at your miserable type system. Do you think anybody who designs type systems built that? No. This is the C type system, it's defective but it was easy to implement. Actually fixing C++ needs a ground-up rebuild, that's what you see (impressively) in Sean Baxter's work for example. I doubt it will make a real difference, but to his credit Sean looked at all the horrible problems and rolled up his sleeves and fixed them with a fairly radical set of required language and library changes, rather than kicking them under a rug and insisting it's all fine, just don't look under the rug.
uecker 2y ago
C can essentially do the same thing. I do not see why C++ would have a fundamental advantage here.

VyseofArcadia 2y ago

It's a social problem. People make mistakes, or are coerced into letting mistakes persist, because you have to get the features out. And if you stand your ground on security, management will find someone who won't. If software "engineers" were engineers who had the duty and authority to say "no, I won't build something unsafe" we'd have fewer problems. Not to say that improved tools isn't also a worthy goal, but why not attack the problem from all angles?

pyeri 2y ago

Those busy humans can always switch to rust or Java? Those ain't bad languages either. And let's face it, given its bare metal nature, there are always going to be limits on how "secure" you can make it in order to "protect" the developer from goofing up in C/C++.

ngneer 2y ago

I agree with almost all of your analysis. One has to be an excellent programmer to write secure code, doubly so in C. I disagree with your conclusion, though. To me, the above means that C FAILS to meet the goal of enabling secure programming. An analogy might be car safety. Yes, if we had perfect drivers we would not even need seatbelts, let alone airbags. But, I would definitely say that a car without these does not meet the goal of "enabling" safe driving merely because it is theoretically possible. https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/812069.pdf https://crashstats.nhtsa.dot.gov/Api/Public/ViewPublication/...