l4-hurd
[Top][All Lists]
Advanced

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

Re: C99 aliasing rules


From: Marcus Brinkmann
Subject: Re: C99 aliasing rules
Date: Mon, 10 Jan 2005 22:19:05 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 10 Jan 2005 09:55:20 +0100,
Ludovic Courtès <address@hidden> wrote:
> 
> Hi,
> 
> On Fri, Jan 07, 2005 at 08:34:04PM +0100, Marcus Brinkmann wrote:
> > Restrict means something completely different: Restrict says that
> > pointers to the _same_ type point to non-overlapping storage.  It is
> > in this sense stricter than the normal aliasing rule.
> 
> Ok, I see.
> 
> > Aliasing is defined in the C standard in section 6.5 (#7).  Good luck
> > in wrapping your head around the wording of the standard.  It took me
> > a couple of days and some research into various usenet discussions,
> > and a perusal of the pending defect reports about this issue to
> > understand the issues involved and to accept the brutality of the
> > aliasing rules.
> 
> However, the example you gave:
> 
>   typedef union
>   {
>     _L4_msg_t _msg;
>     __L4_msg_tag_t tag;
>   } __L4_msg_t;
> 
>   void
>   _L4_msg_get (_L4_msg_t msg, _L4_word_t *untyped, void *any_typed)
>   {
>     __L4_msg_t *_msg = (__L4_msg_t *) msg;
> 
>     ...
>   }
> 
> should work because _msg's type is an aggregate that includes msg's type
> among its members.  Am I missing something?

First, we are outside C99 here in any case.  C99 does not demand type
punning to work.

For GCC, type punning works, but only if both accesses happen
_through_ the union.  Just casting something that is included in the
union to the union type does _not_ work, you are still breaking the
alias rule.  In other words: As far as aliasing is concerned, "int"
and "union { int a; }" are incompatible types.

> If this didn't work, this would prevent any similar use of "structure
> inheritance", which would be quite unfortunate given that it's widely
> used (as in Glib, GTK+, etc.).  If I'm right, it's not _that_ brutal.
> ;-)

Yes, "structure inheritance" breaks aliasing rules, unless you do it
top down.

So, this is ok:

struct a;
struct a_d { struct a a_m; int etc; };

struct a_d a_i;
struct a *ap = &a_i.a_m;

What does not work:

struct a *ap = malloc (sizeof (struct a_d));
struct a_d *adp = (struct adp *) ap;

So, yes, it _is_ brutal, and it does break some widely used idioms and
programming tricks, I don't know if it is done this way in gtk though.

What many projects do in fact is to disable strict aliasing for their
projects.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]