public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Joshua Haberman <jhaberman@gmail.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: GCC aliasing rules: more aggressive than C99?
Date: Sun, 03 Jan 2010 11:06:00 -0000	[thread overview]
Message-ID: <4B407A44.9070409@redhat.com> (raw)
In-Reply-To: <loom.20100103T063932-636@post.gmane.org>

[ redir to gcc-help ]

On 01/03/2010 05:46 AM, Joshua Haberman wrote:
> The aliasing policies that GCC implements seem to be more strict than
> what is in the C99 standard.  I am wondering if this is true or whether
> I am mistaken (I am not an expert on the standard, so the latter is
> definitely possible).
> 
> The relevant text is:
> 
>   An object shall have its stored value accessed only by an lvalue
>   expression that has one of the following types:
> 
>   * a type compatible with the effective type of the object,
>   [...]
>   * 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
> 
> To me this allows the following:
> 
>   int i;
>     *pu = (union u*)&i;
>   printf("%d\n", pu->x);

I do not believe that this is allowed.  A union of type

   union u { int x; }

is not compatible with the type int.  It might have greater alignment,
it might be larger, and so on.  We do know that a pointer to a union
can be converted to a pointer to each of its members and vice versa.
But, and this is crucial, *that does not mean they are compatible
types*.

> In this example, the object "i", which is of type "int", is having its
> stored value accessed by an lvalue expression of type "union u", which
> includes the type "int" among its members.
> 
> I have seen other articles that interpret the standard in this way.
> See section "Casting through a union (2)" from this article, which
> claims that casts of this sort are legal and that GCC's warnings
> against them are false positives:

>   http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

It's wrong.

You need to look at the standard's own definition of what constitutes
a compatible type.

<< 1 Two types have compatible type if their types are the
same. Additional rules for determining whether two types are
compatible are described in 6.7.2 for type specifiers,

...

6.7.2.1

A pointer to a structure object, suitably converted, points to its
initial member (or if that member is a bit-field, then to the unit in
which it resides), and vice versa.>>

Rather than reading dubious web sites, you need to refer to the
standard itself when trying to understand C.  There have been several
attampts to summarize the standard, and as far as I'm aware they are
all unreliable.

So please don't believe me: believe the standard.

Andrew.

       reply	other threads:[~2010-01-03 11:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <loom.20100103T063932-636@post.gmane.org>
2010-01-03 11:06 ` Andrew Haley [this message]
2010-01-05  6:35   ` Patrick Horgan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B407A44.9070409@redhat.com \
    --to=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=jhaberman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).