Re: Strict aliasing, yes or no?

[Emmanuele Bassi <ebassi gmail com>]

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.

Ciao,
 Emmanuele.


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
> indications:
>
> (1) The new meson patches pass -fno-strict-aliasing to GCC and Clang:
> https://git.gnome.org/browse/gtk+/commit/?h=wip/meson&id=1e3daf3178bb3db56ab12a55195969857f685101
> 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
> violations: https://bugzilla.gnome.org/show_bug.cgi?id=140722
>
> 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
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]