[Top][All Lists]
[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
- Re: Contribution to the Hurd on L4, Marcus Brinkmann, 2005/01/06
- Re: Contribution to the Hurd on L4, Matthieu Lemerre, 2005/01/06
- Re: Contribution to the Hurd on L4, Ludovic Courtès, 2005/01/07
- Re: Contribution to the Hurd on L4, Marcus Brinkmann, 2005/01/07
- Re: Contribution to the Hurd on L4, David Leimbach, 2005/01/08
- C99 aliasing rules, Ludovic Courtès, 2005/01/10
- Re: C99 aliasing rules,
Marcus Brinkmann <=
- Re: C99 aliasing rules, Philip Nilsson, 2005/01/14