1. 28
  1.  

    1. 1

      And here it is for Rust (I didn’t do it, but here it is).

    2. 3

      Funny in itself and because he did not cite Regehr and because those irq_chint settings could be legit

      1. 2

        Regehr is cited later.

        1. 2

          Regehr found the example, Bastien thought of scanning through github, and this person posted it as his own idea. Not a big deal - nobody is going to win a Field medal for noticing this - but still it’s not polite.

          Also the IRQ variable is almost certainly using xor as intended to zero the last three bits - it should have been done with defines or constants, but it illustrates the complexity of distinguishing good from bad even for this example.

          1. 4

            It really doesn’t seem that filing this with links to twitter threads is presenting it as their own idea.

            Posting good tickets is also necessary and useful work to be done, I would say they were being helpful.

            1. 1

              but he did not - someone else posted the link.

              1. 1

                Umm the first note in the bug report links to twitter twice. Are you claiming this was edited later?

      2. 4

        The answer is no and the answer will always be no.

        This is one of those cases where pulling on a loose string yields more and more string, which then continues to escalate until the whole construction is in it’s constituent pieces.

        For if the answer would be “yes” as to whether C/C++ compilers should warn on bitshift operators when the user most likely ment exponentiation, then we would end up with the expectation that these compilers should consider programmer intent to be more important than arcane standards and the result would be something that’s no longer C/C++.

        There are hundreds of examples of C/C++ specification lawyering where compilers felt entitled to rely on a strict reading of the specifications to do the unexpected or programmer unfriendly thing, taking “undefined behaviour” as a license to shoot existing codebases in the foot retroactively, usually without warning.

        This is a collective delusion* that’s too late to nip in the bud. One of the distinguishing feature of some newer programming languages (beyond the syntax and semantics) is the vastly different attitude to creating compilers.

        *a bit like how the node community pretends it’s normal to have thousands of separate modules in one’s dependency tree, it’s not normal, but design costs like these are like background radiation

        1. 17

          The answer is no and the answer will always be no.

          Quoting Jonathan Wakely from the bug report:

          There’s nothing wrong about implicit fallthrough, misleading indentation, ambiguous else, or missing parentheses in nested logic expressions either. But people get it wrong all the time.

          Pretty sure the answer is going to be “yes”.

          1. 2

            I’m not sure why you’re equating charging the language semantics with adding warnings, the entire purpose of which is to catch “correct” code that is unlikely to actually have the behaviour intended by the author.

          2. 3

            That seems like a clearly good idea. I’m a bit surprised at the skeptical reaction – surely anyone who would disagree is using gcc -w anyhow?

            1. 2

              I remember making this exact mistake when I was learning C and making an interactive calculator. It was really confusing to me then.

              1. 2

                I wonder why people think this is specific to C. Python, ruby, and javascript all interpret 10^7 as 13.

                1. 2

                  I have no opinion on whether or not the compiler should warn over this, but as somebody for whom the C-family of languages are mostly read-only I’m mostly just glad I’m apparently not the only idiot to confuse these.

                  1. 1

                    It’s alarming how many examples they were able to find. Clearly a lot of this code hasn’t been tested well, or maybe not even at all. Certainly doesn’t help C and C++’s reputation as being dangerous and hard to use.

                    In any case, I don’t care one way or the other about adding the warning. It’s not a mistake I make, so won’t directly affect me.

                    1. 1

                      Regehr’s tweet ended up on my timeline earlier and not one of my friends caught the error. And to be fair I didn’t either, I had to read the replies to figure out what they were talking about.

                      1. 1

                        Generally, there’s a way to ‘work-around’ warnings like that on a case-by-case basis. For instance, [[fallthrough]] (or __attribute__((fallthrough))) for fallthrough in switch; or if ((a=b)) instead of if (a=b). Will there be such a thing for this? If what I actually want is 2^32? I saw proposed in the thread that the warning shouldn’t be present for hex/binary literals, but I don’t consider that a full solution.

                        1. 2

                          If what I actually want is 2^32?

                          2^32 == 2 | 32, so why not just use the latter?

                          1. 1

                            10^7 != 10|7, so what do you do there?

                            1. 2

                              It’s 13.

                          2. 2

                            It is hard for me to imagine a use-case for 2^32, and very easy for me to imagine use cases for 1 << 32; when are you thinking you would use int-constant '^' int-constant? I could see xor-ing bitfield flags or something, but then usually you’re doing something like MASK1 ^ MASK2 using names instead of literals.

                            1. 1
                              #include <stdint.h>
                              #include <stdio.h>
                              int main() {
                                 printf("%u\n", UINT32_MAX);
                              }