Re: Strict aliasing, yes or no?

[Simon McVittie <smcv collabora com>]

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;