1. 13
  1. 4
    1. Absolutely: rework code until warnings are 0 because of exactly this + issues across compilers and platforms

    -2. Did not understand why the fill bits are not 0 but the last bit-


    Gives the answer: its a signed expansion.

    1. 5

      Yes! And I’d go a step further: once you get down to warning-zero, turn on -Werror to make sure no one introduces another warning.

      1. 3

        bonus points for -Wall -Wpedantic

        1. 1

          Not quite. The only warning I let slide is:

          warning: ISO C forbids assignment between function pointer and `void *'

          But that’s because POSIX requires that behavior. But otherwise, yes, I will crank up the warnings when compiling.

      2. 4

        Unfortunately, the code I was using causes lots of warnings when it is compiled, so I missed this one and cost myself some debugging time. The moral of this story is: compile without warnings if at all possible.

        I hope this means “address all warnings such that the compiler emits no warnings” but it sounds just a teeny bit like “disable the warnings.”

        I’d add that once you address all the warnings consider also using ASan+UBSan on your test runs, maybe consider passes for MSan and/or TSan.

        1. 3

          If you’re not going to look at the warnings because there are too many, it makes a lot of sense to disable the ones you’re not going to fix so you can look for warnings you will fix.

          1. 1

            That’s also a best practice in using static analysis tools in environments with time constraints and/or apathy. Better to let them fix some and ignore some than to have them avoid the tools entirely.

          2. 2

            I think this is satire.