Re: (no) strict aliasing

[Marcus Brinkmann]

At 31 Oct 2004 16:06:46 -0800,
Thomas Bushnell BSG wrote:
> 
> Marcus Brinkmann <address@hidden> writes:
> 
> > The only way I found to make allocators like ports_create_port to
> > reliably work without disabling aliasing alltogether would be to have
> > the function return void * and use the __malloc__ function attribute.
> 
> Shouldn't the __malloc__ attribute work, even if you don't return a
> type like void *?

I don't know.  But I have to correct me.  My understanding of the
malloc attribute was flawed.  Even if it does work, it only causes
more optimization opportunities, not less.  I basically tells the
compiler that the returned pointer is not the alias of any other
object.

(And hey, if you need a futile challenge, try to figure out if it is
correct for realloc() to have that attribute or not.  Good luck.)

> > I am hitting similar problems in the code I write for the L4 port.  I
> > was wondering what you think about it -- if we should disable strict
> > aliasing globally, or fix such code individually.
> 
> In my opinion, we should demand a GCC feature that allows us to
> disable it on a per-function basis.

GCC has one such attribute for types, may_alias, which says that this
type may always alias any other type.  It seems to be a bit of a
sledgehammer, and I am not sure about its proper use (ie, which of the
types would need it).  I guess it could be used for the types we are
looking at.

I have by now done even some more studies, and this issue is really
nagging at my patience.  From reading lots and lots of discussion on
various gcc and egcs lists, comp.lang.c, comp.std.c, and defect
reports and meeting minutes of WG14, I start to think that this whole
alias thing is work in progress, and pretty much of a mess.  It's very
much true that they make C a high-level language, and not the portable
assembler that we need.

Currently, I am very close to giving up on this and to define
-fno-strict-aliasing, at least until they have made up their mind.
Anybody who disagrees should be prepared to explain me the penultima
rule in 6.5p7 of ISO C99:

      [#7] An object shall have its stored value accessed only  by
       an lvalue expression that has one of the following types:73)

[...]

        -- an aggregate or union type that  includes  one  of  the
           aforementioned  types  among  its  members  (including,
           recursively, a member of a  subaggregate  or  contained
           union), or

Even the committee doesn't seem to agree on what it means (see for
example N980 at
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n980.htm)

I admit frankly to be confused about this.  I think I start to get a
feel at what the language lawyers want to achieve, but I don't like
it.  It makes it more difficult to extend library-managed objects
dynamically in the way we want to do it.  (The only way I can think of
is to push the allocation to the higher level, and assign it to the
biggest object first, then derive the pointers to the sub objects.
Ie, only cast downwards the object hierarchy).

What really bugs me about it is that all the discussion and examples
about this usually use the construct of writing to an integer pointer
and reading it out as a float (or vice versa), and never actually
useful cases like structs with common initial members (which is only
ever discussed in the context of a union, ie, when you have a 
relationship known at compile time).

'Nuff ranting.

Thanks,
Marcus