3 ms·

As a frequent poster of C answers on Stack Overflow, this is a succinct way of expressing the realities of programming in a language with undefined behavior ("U

by unwind 9y ago

As a frequent poster of C answers on Stack Overflow, this is a succinct way of expressing the realities of programming in a language with undefined behavior ("UB"). Many newcomers to C seem to think that just because they wrote something, and it compiled, and it had the expected output, they wrote a correct program. But since there can be UB which results in any (hence undefined) behavior, including whatever the person expected, that really isn't true. Unfortunately that seems to go against many people's expectations/intuition. :/

MaxBarraclough 9y ago
A valid pet-peeve. <ramble> Conflating a working build for good code, isn't specific to C. Students being taught Java (or any other safe language with an explicit verification/compilation phase) can also be tempted to assume that just because their code finally compiles ok, then it must be the program they hoped to write. Then there's the issue of the code working for one or two particular combinations of inputs, but not all. Again, failure to test well is not specific to C. There is the possibility that the UB only rears its ugly head in very rare circumstances, but again, obscure bugs slipping past testing isn't specific to C. Where C is unique is that, as you say, even where the resulting binary always gives the right outputs (on your current compiler+platform), that doesn't mean you have a 'truly correct' C program, even assuming that platform independence is a non-goal. To put it another way, exhaustively demonstrating the correctness of the resulting binary, doesn't prove the correctness of the C program. This isn't the case for all other languages, however - sometimes exhaustive testing of the binary can prove program-correctness. (At least, if we ignore non-deterministic runtime factors like threads' scheduling and RNGs. One could concoct a deterministic subset of Java that would have this property.) Regarding multi-platform code: It's not just UB that gives C the ability to behave so differently between different compilers/platforms. If you switch platform and are suddenly subjected to a new width of unsigned int, your code might behave differently in this new environment (it might fail to wrap-around when it used to, say) even if it never invokes UB. </ramble> > that seems to go against many people's expectations/intuition In an ideal world we'd take the edge off by requiring all new C programmers to use something akin to Clang's 'ubsan' runtime UB detector.
AnIdiotOnTheNet 9y ago
That's because the general idea that something that works as intended is wrong is counter to reality. In your example of Undefined Behavior, the UB is only a problem if you encounter a system that behaves differently, which in many cases doesn't really exist or is not applicable to the problem being solved. Even so, just because behavior is defined doesn't mean that behavior is implemented properly.
hinkley 9y ago
If you don’t actually understand how something works, how will you fix it when it doesn’t?

by unwind 9y ago

MaxBarraclough 9y ago

A valid pet-peeve. <ramble> Conflating a working build for good code, isn't specific to C. Students being taught Java (or any other safe language with an explicit verification/compilation phase) can also be tempted to assume that just because their code finally compiles ok, then it must be the program they hoped to write. Then there's the issue of the code working for one or two particular combinations of inputs, but not all. Again, failure to test well is not specific to C. There is the possibility that the UB only rears its ugly head in very rare circumstances, but again, obscure bugs slipping past testing isn't specific to C. Where C is unique is that, as you say, even where the resulting binary always gives the right outputs (on your current compiler+platform), that doesn't mean you have a 'truly correct' C program, even assuming that platform independence is a non-goal. To put it another way, exhaustively demonstrating the correctness of the resulting binary, doesn't prove the correctness of the C program. This isn't the case for all other languages, however - sometimes exhaustive testing of the binary can prove program-correctness. (At least, if we ignore non-deterministic runtime factors like threads' scheduling and RNGs. One could concoct a deterministic subset of Java that would have this property.) Regarding multi-platform code: It's not just UB that gives C the ability to behave so differently between different compilers/platforms. If you switch platform and are suddenly subjected to a new width of unsigned int, your code might behave differently in this new environment (it might fail to wrap-around when it used to, say) even if it never invokes UB. </ramble> > that seems to go against many people's expectations/intuition In an ideal world we'd take the edge off by requiring all new C programmers to use something akin to Clang's 'ubsan' runtime UB detector.

AnIdiotOnTheNet 9y ago

That's because the general idea that something that works as intended is wrong is counter to reality. In your example of Undefined Behavior, the UB is only a problem if you encounter a system that behaves differently, which in many cases doesn't really exist or is not applicable to the problem being solved. Even so, just because behavior is defined doesn't mean that behavior is implemented properly.

hinkley 9y ago

If you don’t actually understand how something works, how will you fix it when it doesn’t?