
Compiler Warnings - ingve
https://fastcompression.blogspot.com/2019/01/compiler-warnings.html
======
deogeo
> If a warning message is considered not fixable, or not desirable to fix,
> it’s preferable to remove the associated flag from the build chain.

I like to use diagnostic pragmas
([https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-
Pragmas.html](https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html)) in
the vanishingly rare cases where I can't fix the cause of a warning.

~~~
berti
This unfortunately gets messy when you're targeting multiple compilers, and in
some cases multiple versions of the same compiler.

~~~
deogeo
At least clang has it covered:
[https://clang.llvm.org/docs/UsersManual.html#pragma-gcc-
diag...](https://clang.llvm.org/docs/UsersManual.html#pragma-gcc-diagnostic)

Don't know what the situation is on MS's and Intel's compilers.

~~~
raptorfactor
The same functionality is available: [https://docs.microsoft.com/en-
us/cpp/preprocessor/warning?vi...](https://docs.microsoft.com/en-
us/cpp/preprocessor/warning?view=vs-2017)

~~~
MaulingMonkey
And you can use _Pragma / __pragma to hide them inside (conditional) macros
without #ifdefing up every call site.

There are still edge cases where you can't sanely scope them relating to when
templates are evaluated, being unable to use the pragmas at arbitrary points
of an expression, warnings that don't respect the warning flags properly, etc.
- but it works most of the time.

That said, for warnings with high false positives and low value true
positives, I'll just globally suppress the warning.

------
loeg
Some context: the author is Yann Collet, the principal author of zstd, lz4,
and xxHash. In my experience he is an extremely talented and friendly
engineer.

------
kazinator
> _-Wdeclaration-after-statement : this flag is useful for C90 compatibility._

This option is rather for developers who want to avoid declarations after
statements in C dialects that support them.

If you want to enforce actual C90 compatibility use -ansi or -std=c90.
Otherwise you just have partial compatibility which is actually
incompatibility.

------
olliej
All of this seems fine, except for the floating point but.

Floating point is completely deterministic, and has a very clearly defined set
of behaviours.

~~~
wyattpeak
I don't know much about the C standard, but the article states that
implementation details are platform-specific. If that's the case, it's a very
sensible suggestion.

Sure, if the same system runs the same operation twice, the two values will be
equal. But what if you're comparing to a stored value generated on a different
system?

~~~
gizmo686
It doesn't even need to be a different system. Different compilations of the
same program on the same system can result in different floating point results
(either because of internal high-precision floating point registers being
utilized differently, or the compiler making algebraically valid re-
arrangements that change the floating point result).

Additionally, many usages of == assume basic algebraic properties of numbers
to hold.

It is possible to use equality with floats, but require far more care than is
typically worth it.

~~~
olliej
If the optimization level changes the behaviour the compiler is broken.
“Optimizing” by assuming commutivity or associativity of floating point is no
less incorrect than optimizing by assuming string addition was commutativeand
associative.

~~~
gizmo686
There is no requirement that optimization does not change behaviour. The only
requirement is that the optimized behavior remains consistent with the
standards. The point of the point on floating point equality is that the
standards give enough room for variance that you should not use literal
equality unless you know exactly what you are doing and have a good reason for
doing it.

As an aside, if your concern is that the standards impose too much
restrictions, another popular option is the ffast-math option.

We see this come up with strings fairly often in higher level languages where,
sometimes, logical equal strings will happen to be equal because the runtime's
interning system made them point to the same location, but there is no
guarantee this would happen and the implementation is free to change it at any
point. I believe I have also seen this behaviour come up with interning on
some Integer wrapper types.

~~~
loeg
> I believe I have also seen this behaviour come up with interning on some
> Integer wrapper types.

Python, for example:

    
    
      >>> 8 is 8
      True
      >>> 8**1000 is 8**1000
      False

~~~
olliej
Because python is broken in this respect -- JS engines do exactly the same
object optimisations and get comparisons correct.

~~~
loeg
Meh. They're different languages with different expectations. "is" is distinct
from "==" in both, and Python gets "==" right (obviously). Javascript doesn't
really have any high ground here[0]. (In contrast, Python:)

    
    
      >>> [] == False
      False
      >>> object() == False
      False
      >>> "" == False
      False
      >>> {} == False
      False
    

They're just different.

[0]:
[https://www.youtube.com/watch?v=et8xNAc2ic8](https://www.youtube.com/watch?v=et8xNAc2ic8)

