"Real hardware" is also an abstract machine. Until you get to the level of each individual transistor, it's hardware abstractions all the way down. Caches, reorder buffers, load and store buffers, instruction decoding are all abstract concepts sitting at a much higher level than the individual transistor.
Those abstractions are there mostly for the purpose of speeding up code execution, but also for enabling hardware designers to think about the machine in terms of real-world concepts and not just as an incomprehensible mind-blowing collection of a few billion transistors.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
WG 14 doesn't seem that interested in improving C's security story.
Right now I see more efforts coming out Microsoft and static analysis tool vendors than any WG 14 mailing.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavi…
Implementation defined behaviour is not the same as undefined behavior.
I don't think anyone suggests using C as an alternative for microarchitecture classes. C still remains one of the best ways to access hardware relative to other software languages. No language is "how computers work" unless you're writing Verilog, but C is the closest to the metal relative to other software paradigms while still being more convenient than assembly.
To be fair, even assembly language isn't how the computer works (gets translated into micro code). Not to mention other integral components like the GPU that are coded in an entirely different model. I think what's fair to say is: the "abstract C machine" tends to have a minimal amount of concepts on top of the machines instruction set, compared to other languages, and generally provides the least friction if you nee…
Not really, assembly language is extremely close to microcode, much much closer than it is to C. C has a whole bunch of baggage like pointer provenance, inability to read uninitialized memory, doesn't understand cache aliasing, etc that don't fit hardware well.
Agreed, The example the author uses in his previous post on the topic talks about cache-unaware code but it's perfectly possible to write cache-unaware code in machine language as well. I'd say "C is not how the computer works ... but it's much, much closer than nearly every other language."
I feel your statement is actually much closer to the danger. C is pretty close to the hardware indeed and that misleads people into thinking that C is actually exactly how the hardware works. It's a very easy trap to fall into and I've seen many colleagues do just that.
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavi…
While this is the ideal theory I think we've all seen how it simply doesn't pan out in practice.
The numerous and regular terrifying security bugs that are being found in ancient tools (some 30+ years old) are a living testament that the philosophy you quoted just doesn't translate that well into the reality of humans programming the current breed of computers.
Hence the existence of languages like Rust and the recent general strive towards more correctness and more compile-time catching of potential problems (especially in light of GCC 10's new `-fanalyzer` flag).
Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting…
> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavi…
All the other low level stuff of C can be handled by a professional programmer in different ways, using tools like Valgrind, with careful coding, but especially with higher order libraries, so you don't have to write much low level code. Any language is dangerous and bug prone if the standard library has no dynamic strings and basic data structures. If you have the right tools, C becomes a lot more high level, a lot more safe, and has a long story of solving very important problems reliably and in a portable way.
> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavi…
This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.
> This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous.
If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve.