Re: Strict aliasing, yes or no?

I added the compiler warnings by merging what I use in libepoxy,
graphene, json-glib, and what's in the existing autotools build. That
was done mostly to get the ball rolling, not as a commentary on
whether strict aliasing rules are good or bad.

In general, I'd expect us to review the compiler warnings we use, and
add or subtract what we agree upon as a project.


On 18 April 2017 at 23:05, Daniel Boles <dboles src gmail com> wrote:
Just wondering what the position on this is. I've seen a few conflicting

(1) The new meson patches pass -fno-strict-aliasing to GCC and Clang:
The rationale is "We don't want to build buggy code." Well, technically,
code that relies on aliasing is
inherently buggy from the outset, because that violates the standard.
Assuming that's not something you strive for, the next bit is worse: I can't
see an equivalent directive for MSVC. Surely this means, without forcing the
compiler to make aliasing well-defined, code that relies on aliasing is free
to start wildly bugging out on MSVC at any time?

(2) The Autotools build files do not seem to pass this flag, indicating that
avoidance of strict aliasing was not a requirement.

(3) There's this old bug (and possibly others) to remove aliasing

So, which is true? Do we want to forbid breaking strict aliasing rules, or
do we want to require compilers that allow us to override the Standard and
rely on aliasing violations?

gtk-devel-list mailing list
gtk-devel-list gnome org

[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]