Re: Strict aliasing, yes or no?

[Morten Welinder]

You're right.  On re-reading that I find that it came out harsher than
it ought to have.  My apologies.

Morten


On Thu, Apr 20, 2017 at 7:14 AM, Emmanuele Bassi  wrote:
> On 19 April 2017 at 13:29, Morten Welinder  wrote:
>
>> glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
>> are for performance -- \0 filling, for example -- while others are pure 
>> laziness
>> and ignorance such as variables called "read" or macros name starting with 
>> "E".
>
> Morten, I know you have had your issues with the GTK developers, but
> I'd appreciate it if you refrained from telling people they are "lazy
> and ignorant". This is not the first time you're treading the needle
> of outright insulting people in the GTK community.
>
> I'd like to remind everyone (myself included) that the GTK development
> mailing list operates under the same Code of Conduct of the GNOME
> Foundation as any other service provided by the GNOME infrastructure.
> It's important that all the discussion venues are kept civil and
> welcoming places for everyone.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Emmanuele Bassi]

On 19 April 2017 at 13:29, Morten Welinder  wrote:

> glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
> are for performance -- \0 filling, for example -- while others are pure 
> laziness
> and ignorance such as variables called "read" or macros name starting with 
> "E".

Morten, I know you have had your issues with the GTK developers, but
I'd appreciate it if you refrained from telling people they are "lazy
and ignorant". This is not the first time you're treading the needle
of outright insulting people in the GTK community.

I'd like to remind everyone (myself included) that the GTK development
mailing list operates under the same Code of Conduct of the GNOME
Foundation as any other service provided by the GNOME infrastructure.
It's important that all the discussion venues are kept civil and
welcoming places for everyone.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Chris Vine]

On Wed, 19 Apr 2017 22:12:24 +0100
Chris Vine  wrote:
> On Wed, 19 Apr 2017 12:21:06 +0100
> That (GArray to GRealArray) does break the strict aliasing rules,
> unless done through a union (OK with unions in C99 with Technical
> Corrigendum 3 and in C11, implementation defined only in C89, but
> fine with gcc and clang).

Perhaps I should add that is also valid C89/99/11 if you cast pointer
values with memcpy(), which will be optimized out with any decent
compiler (such as gcc and clang).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Chris Vine]

On Wed, 19 Apr 2017 12:21:06 +0100
Simon McVittie  wrote:
> On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote:
> > Well, technically, code that relies on aliasing is
> > inherently buggy from the outset, because that violates the
> > standard.  
> 
> Not relying on aliasing forbids casting between dissimilar types,
> which rules out "normal" C tricks like casting between GArray and
> GRealArray (where GRealArray starts with the same members as GArray)
> as a way to have a partially-opaque struct, or an
> opaque-other-than-size struct on the stack; so regardless of whether
> it might be desirable to be writing Standard C, I'm not sure that
> GLib can do that without breaking its API.

That (GArray to GRealArray) does break the strict aliasing rules, unless
done through a union (OK with unions in C99 with Technical Corrigendum 3
and in C11, implementation defined only in C89, but fine with gcc and
clang).

I think most reasonable C programmers have roughly got to grips with
strict aliasing now.  Presumably this dates back to less illuminated
times.
 
> It is also not particularly clear from ISO/IEC 9899:201x draft N1570
> (which is essentially the same document as Standard C, but without the
> price tag) whether the usual C pseudo-object-orientation idiom[1]
> (which is a fairly fundamental part of GObject) is considered to be
> valid in Standard C.

That is and always has been perfectly valid C.  You can always cast a
pointer to one type to a pointer to the effective type of the pointee
and dereference it.  It so happens that the initial address of a struct
has two effective types in C, that of the struct itself and that of its
first member, which are required to have the same address.  You don't
even need to rely on the fifth bullet of §6.5/7 of C11 - it is covered
by the basic proposition in the first bullet.

Chris
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Morten Welinder]

You are making the situation sound a bit worse than it actually is.

> Not relying on aliasing forbids casting between dissimilar types, which
> rules out "normal" C tricks like casting between GArray and GRealArray
> (where GRealArray starts with the same members as GArray) as a way to have
> a partially-opaque struct, or an opaque-other-than-size struct on the stack;
> so regardless of whether it might be desirable to be writing Standard
> C, I'm not sure that GLib can do that without breaking its API.

C99 can do that, although access needs to be via a union type.
C99 section 6.5.2.2 #5.  No API break would be need to do it.


> whether the usual C pseudo-object-orientation idiom[1] (which
> is a fairly fundamental part of GObject) is considered to be valid in
> Standard C

That works fine.  C99 section 6.7.2.1 #12.

glib (etc) _is_ stomping on the standard in a hundred different ways.  Some
are for performance -- \0 filling, for example -- while others are pure laziness
and ignorance such as variables called "read" or macros name starting with "E".

Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Simon McVittie]

On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote:
> Well, technically, code that relies on aliasing is
> inherently buggy from the outset, because that violates the standard.

Not relying on aliasing forbids casting between dissimilar types, which
rules out "normal" C tricks like casting between GArray and GRealArray
(where GRealArray starts with the same members as GArray) as a way to have
a partially-opaque struct, or an opaque-other-than-size struct on the stack;
so regardless of whether it might be desirable to be writing Standard
C, I'm not sure that GLib can do that without breaking its API.

It is also not particularly clear from ISO/IEC 9899:201x draft N1570 (which
is essentially the same document as Standard C, but without the
price tag) whether the usual C pseudo-object-orientation idiom[1] (which
is a fairly fundamental part of GObject) is considered to be valid in
Standard C. In general, the aliasing rules are not well-understood,
so it is pragmatic to disable aliasing-driven optimizations in code that
is not CPU-bound.

Most of GNOME is written in pragmatic C (whatever works in gcc and clang
on CPUs that are used in the real world, sometimes with the additional
constraint of also working on MSVC/Windows/x86), not in Standard C. For
instance, standard C doesn't guarantee that 8, 16, 32 and 64-bit types
exist (it only mandates the names like int32_t if such types already
exist!), but GLib requires a type of each of those sizes. Standard C doesn't
guarantee that a pointer with all bits zero is NULL, but GLib libraries
(and probably GLib itself) commonly require that. There are plenty more
examples, many of them things that a typical C programmer is likely to
assume to be always true even though Standard C does not actually
guarantee it.

S

[1] typedef struct { ... } GObject;
typedef struct { GObject parent; ... } MyObject;
typedef struct { MyObject parent; ... } MySubclassObject;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Strict aliasing, yes or no?

[Emmanuele Bassi]

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  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=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]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Strict aliasing, yes or no?

[Daniel Boles]

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=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