4 ms·

> whether our code is being compiled sensibly or not I'm failing to see what's not sensible about how that code is compiled. The only possible way that functi

by moefh 3y ago

> whether our code is being compiled sensibly or not I'm failing to see what's not sensible about how that code is compiled. The only possible way that function could return false is if you read past the end of the array and the value there happens to be different from `v`. Is it really the more sensible to rely on that, rather than fixing a known behavior in case of array overflow?

robinsonb5 3y ago
If the compiler's going to interpret undefined behaviour as license to do something that runs counter to the programmer's expectations, the most sensible course of action is for the compiler to yell very loudly about it instead of near-silently producing (differently!) broken code. Currently that piece of code doesn't trigger a warning with -Wall. It's not even flagged with -Wextra - it needs -Weverything.
- moefh 3y ago
  One man's "broken code produced by the compiler" is another man's "excellently optimized code by the compiler". Where to draw the line is not always clear, but here's a very clear-cut example[1] where emitting a warning would be bad. If you don't want to watch the video, it's basically this: - the code technically contains undefined behavior, but it will never be actually triggered by the program - changing the code to remove undefined behavior forces the compiler to emit terrible code Making the compiler yell at the programmer in this case would be terrible, but it's clearly a consequence of what you're asking. [1] https://youtu.be/yG1OZ69H_-o?t=2358 https://youtu.be/yG1OZ69H_-o?t=2358
  - jeffbee 3y ago
    Exactly. I think a lot of this noise is by non-practitioners of the language. The compiler is steel-manning this loop. It is generously interpreting the 4 as irrelevant, and deducing that the loop must always exit early. The author can’t possibly have meant to access beyond the end, because that’s not defined. QED. It seems altogether sensible to me.
    - Joker_vD 3y ago
      Wow, I must congratulate you because this reads equally well both as a serious argument and as a parody of that argument. So let me reply to your comment as if it were serious: yes, if the programmer by supernatural means knows that the "v" is always presented somewhere in the array, then this function works exactly as intended: it would always return true, and the compiler optimises it to do so as quickly as possible! But... perhaps there is some other way to pass such programmer's knowledge ("the arguments are guaranteed to be such that this loop is guaranteed to finish early") to the compiler in a more explicit way? Some sort of explicitly written assertion? A pre-condition? A contract, if you like? See, it's very difficuly to maintain such unspoken contracts and invariants during the codebases' life because they're unspoken and unwritten. Comments barely count since compilers generally ignore them.
      - jeffbee 3y ago
        Thanks! I think anyone would have to be nuts to write a loop like this in C++ or tolerate C as a language. C++'s `ranges::find` does what it says, and communicates between the author and the reader as well as the author and the compiler.
  - robinsonb5 3y ago
    > One man's "broken code produced by the compiler" is another man's "excellently optimized code by the compiler". To be fair it's not the compiler's fault that the source program is broken - the argument is over whether the compiler is being helpful or being obtuse, and this particular case I'd argue the latter. Thanks for the video link - it's an interesting example, but the crucial difference there, I think, is that in that case the compiler isn't doing something counter to the programmer's intent. The code isn't incorrect (assuming a non-pathological buffer size) - it's merely more convenient for the compiler when expressed with int32_t indices rather than uint32_t indices. I do appreciate, though, that deciding what to yell about and what not to yell about is an extremely non-trivial problem.

by moefh 3y ago

robinsonb5 3y ago

If the compiler's going to interpret undefined behaviour as license to do something that runs counter to the programmer's expectations, the most sensible course of action is for the compiler to yell very loudly about it instead of near-silently producing (differently!) broken code. Currently that piece of code doesn't trigger a warning with -Wall. It's not even flagged with -Wextra - it needs -Weverything.

moefh 3y ago
One man's "broken code produced by the compiler" is another man's "excellently optimized code by the compiler". Where to draw the line is not always clear, but here's a very clear-cut example[1] where emitting a warning would be bad. If you don't want to watch the video, it's basically this: - the code technically contains undefined behavior, but it will never be actually triggered by the program - changing the code to remove undefined behavior forces the compiler to emit terrible code Making the compiler yell at the programmer in this case would be terrible, but it's clearly a consequence of what you're asking. [1] https://youtu.be/yG1OZ69H_-o?t=2358 https://youtu.be/yG1OZ69H_-o?t=2358
- jeffbee 3y ago
  Exactly. I think a lot of this noise is by non-practitioners of the language. The compiler is steel-manning this loop. It is generously interpreting the 4 as irrelevant, and deducing that the loop must always exit early. The author can’t possibly have meant to access beyond the end, because that’s not defined. QED. It seems altogether sensible to me.
  - Joker_vD 3y ago
    Wow, I must congratulate you because this reads equally well both as a serious argument and as a parody of that argument. So let me reply to your comment as if it were serious: yes, if the programmer by supernatural means knows that the "v" is always presented somewhere in the array, then this function works exactly as intended: it would always return true, and the compiler optimises it to do so as quickly as possible! But... perhaps there is some other way to pass such programmer's knowledge ("the arguments are guaranteed to be such that this loop is guaranteed to finish early") to the compiler in a more explicit way? Some sort of explicitly written assertion? A pre-condition? A contract, if you like? See, it's very difficuly to maintain such unspoken contracts and invariants during the codebases' life because they're unspoken and unwritten. Comments barely count since compilers generally ignore them.
    - jeffbee 3y ago
      Thanks! I think anyone would have to be nuts to write a loop like this in C++ or tolerate C as a language. C++'s `ranges::find` does what it says, and communicates between the author and the reader as well as the author and the compiler.
- robinsonb5 3y ago
  > One man's "broken code produced by the compiler" is another man's "excellently optimized code by the compiler". To be fair it's not the compiler's fault that the source program is broken - the argument is over whether the compiler is being helpful or being obtuse, and this particular case I'd argue the latter. Thanks for the video link - it's an interesting example, but the crucial difference there, I think, is that in that case the compiler isn't doing something counter to the programmer's intent. The code isn't incorrect (assuming a non-pathological buffer size) - it's merely more convenient for the compiler when expressed with int32_t indices rather than uint32_t indices. I do appreciate, though, that deciding what to yell about and what not to yell about is an extremely non-trivial problem.