3 ms·

It's not a bug only in the sense that it's intentional. It's certainly not "good" or a feature any other language should ever copy again because it prevents you

It's not a bug only in the sense that it's intentional. It's certainly not "good" or a feature any other language should ever copy again because it prevents you from saying anything formally about the properties of the system at time T, when UB has occurred or will occur at any point along the execution path. As a result, you're always stuck with the qualification that x is true in the absence of UB, something that no automated checker can ever verify and careful review is insufficient to validate in the real world. Whether or not this is a common issue on commodity hardware is basically irrelevant given C's remaining niche. It's mainly the language of kernels, drivers, and firmware nowadays, not primitive CLI tools that can crash whenever they feel like it. Ensuring system state with high reliability is the raison d'etre of modern C, so the lack of ways to do that without significant caveats is incredibly problematic.

shadowgovt 3y ago
That's the tricky part. As the amount of parallelism required to eke out more performance approaches infinity, the amount we can say about the properties of the system at time T approaches zero. Determinism is actually the enemy here. > It's mainly the language of kernels, drivers, and firmware nowadays, not primitive CLI tools that can crash whenever they feel like it On this we completely agree; I would encourage pushing implementation of command line tools in C as close to zero as possible. It isn't necesary to get maximum performance (either because those tools don't demand it or because we have other langauges that make better safety-performance tradeoffs to get us, on average, as fast as C without sacrificing things like memory-access safety).
- AlotOfReading 3y ago
  If we can't say anything about the system at time T, that's a failure of the execution model. I'm not trying to implicate Rice's theorem here or other undecideable problems. C makes it difficult to correctly implement any code (rather than all code) that has a property we want and show that it holds solely with the tools available to mortals. Divine intervention is helpful, but notoriously unreliable.
  - shadowgovt 3y ago
    This is probably my bias just from all of the distributed work I've had to do, but in general being able to say anything about the state of the system at a discrete time T is an expensive luxury in my ecosystem, If not actually infeasible. You can say things about the expected input and output, you can reason about how it's supposed to get there, and you can do traces of a discrete path that was taken in hindsight. But being able to pause the universe and say "What is the current state of the machine" isn't possible when the 'machine' is spread across data centers in multiple geographic locations and it's barely, if we turn our head and squint and lie to ourselves, possible on a modern CPU architecture with SIMD instructions and branch prediction.
    - AlotOfReading 3y ago
      Totally agree, but it's a bit outside C. The C execution model is essentially built around the idea of a single-thread computer with a flat memory space, with very minor considerations for exceptions hidden in UB throughout the standard. Most of the difficult and expensive consistency stuff is punted outside the language or to other standards like Cilk and UPC, though recent versions have at least recognized that threads and parallel processors exist.
      - jstimpfle 3y ago
        Other languages aren't much different in this regard (other than often being less well specified), because it's the reasonable thing to do. You want to give threads a lot of independence for performance reasons. But people just love to shit on C.
        AlotOfReading 3y ago
        Yes, many popular languages are even worse. Thankfully most of those languages (C++ excepted) aren't used for systems programming like C is and hopefully we can agree that the safety story with C++ is mixed at best. Those that have some history as real systems languages (e.g. Java) tend to have pretty decent execution semantics. But just to provide a real counterargument, Ada/SPARK meets the bars I set above. Rust is also a significant improvement over C in practical terms, even if there isn't an official standard you can point to in the same way.

shadowgovt 3y ago

That's the tricky part. As the amount of parallelism required to eke out more performance approaches infinity, the amount we can say about the properties of the system at time T approaches zero. Determinism is actually the enemy here. > It's mainly the language of kernels, drivers, and firmware nowadays, not primitive CLI tools that can crash whenever they feel like it On this we completely agree; I would encourage pushing implementation of command line tools in C as close to zero as possible. It isn't necesary to get maximum performance (either because those tools don't demand it or because we have other langauges that make better safety-performance tradeoffs to get us, on average, as fast as C without sacrificing things like memory-access safety).

AlotOfReading 3y ago
If we can't say anything about the system at time T, that's a failure of the execution model. I'm not trying to implicate Rice's theorem here or other undecideable problems. C makes it difficult to correctly implement any code (rather than all code) that has a property we want and show that it holds solely with the tools available to mortals. Divine intervention is helpful, but notoriously unreliable.
- shadowgovt 3y ago
  This is probably my bias just from all of the distributed work I've had to do, but in general being able to say anything about the state of the system at a discrete time T is an expensive luxury in my ecosystem, If not actually infeasible. You can say things about the expected input and output, you can reason about how it's supposed to get there, and you can do traces of a discrete path that was taken in hindsight. But being able to pause the universe and say "What is the current state of the machine" isn't possible when the 'machine' is spread across data centers in multiple geographic locations and it's barely, if we turn our head and squint and lie to ourselves, possible on a modern CPU architecture with SIMD instructions and branch prediction.
  - AlotOfReading 3y ago
    Totally agree, but it's a bit outside C. The C execution model is essentially built around the idea of a single-thread computer with a flat memory space, with very minor considerations for exceptions hidden in UB throughout the standard. Most of the difficult and expensive consistency stuff is punted outside the language or to other standards like Cilk and UPC, though recent versions have at least recognized that threads and parallel processors exist.
    - jstimpfle 3y ago
      Other languages aren't much different in this regard (other than often being less well specified), because it's the reasonable thing to do. You want to give threads a lot of independence for performance reasons. But people just love to shit on C.
      - AlotOfReading 3y ago
        Yes, many popular languages are even worse. Thankfully most of those languages (C++ excepted) aren't used for systems programming like C is and hopefully we can agree that the safety story with C++ is mixed at best. Those that have some history as real systems languages (e.g. Java) tend to have pretty decent execution semantics. But just to provide a real counterargument, Ada/SPARK meets the bars I set above. Rust is also a significant improvement over C in practical terms, even if there isn't an official standard you can point to in the same way.