From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28964 invoked by alias); 19 Feb 2011 18:23:41 -0000 Received: (qmail 28956 invoked by uid 22791); 19 Feb 2011 18:23:40 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,TW_BZ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from web130201.mail.mud.yahoo.com (HELO web130201.mail.mud.yahoo.com) (66.94.238.137) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sat, 19 Feb 2011 18:23:36 +0000 Received: (qmail 94397 invoked by uid 60001); 19 Feb 2011 18:23:34 -0000 Message-ID: <306891.92576.qm@web130201.mail.mud.yahoo.com> Received: from [76.244.82.88] by web130201.mail.mud.yahoo.com via HTTP; Sat, 19 Feb 2011 10:23:34 PST Date: Sat, 19 Feb 2011 19:01:00 -0000 From: xorbe Subject: Re: alias question To: Segher Boessenkool Cc: gcc-help@gcc.gnu.org In-Reply-To: <56330.94.211.195.167.1298053891.squirrel@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg00298.txt.bz2 > That's not C code. I have no idea about > the rules in C++.. Apology, I'll try to stick to C code. > > What?=A0 You can access any type with a char type, > > this is a specific exception. >=20 > Yes.=A0 And you cannot access a char as any type.=A0 > The exception is not symmetric in that way. I looked this up. That's just legalese wording to stop the following "logic" of attempting to alias through char: uint32_t *d; char *c =3D (char*)d; /* okay */ uint16_t *s =3D (uint16_t*)c; /* bzzt spec says no! */ Clearly the above code will fail when written by *s and read by *d, or vice-versa. Not because we created an alias to char, but because we sneakily created an alias between two different non-char types through the char pointer. If there is only char + one type in question, then the reality is that it make no difference which order the aliases are created. There are two pointers that alias each other. One can't say that the char aliases the type, or that the type aliases the char, it's equivalent at that point. My example is different that any other example that I could dig up on the web. I've concluded that the reason my example code is valid and works is because there are only char writes. Any other type of read to the same region will always see the char writes, even if those other reads happen to overlap. Counter-example code that breaks always welcome! Thanks, Jason