This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC aliasing rules: more aggressive than C99?
On Mon, Jan 04, 2010 at 08:17:00PM +0000, Joshua Haberman wrote:
> Andrew Haley <aph <at> redhat.com> writes:
> > On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> > > Andrew Haley <aph <at> redhat.com> writes:
> > "6.3.2.3
> >
> > "A pointer to an object or incomplete type may be converted to a
> > pointer to a different object or incomplete type. If the resulting
> > pointer is not correctly aligned for the pointed-to type, the
> > behavior is undefined. Otherwise, when converted back again, the
> > result shall compare equal to the original pointer."
> >
> > This is *all* you are allowed to do with the converted pointer. You
> > may not dereference it.
>
> The text you quoted does not contain any "shall not" language about
> dereferencing, so this conclusion does not follow.
It doesn't have to use any "shall not" language. If the standard does not
say that any particular action is allowed or otherwise defines what it
does, then that action implicitly has undefined behaviour.
>
> > [Section 6.3.2.3] is the core rule that governs C's aliasing.
>
> Section 6.5 paragraph 7 contains this footnote:
>
> The intent of this list is to specify those circumstances in which an
> object may or may not be aliased.
>
> I am not sure why you discard the significance of this section. Also
> under your interpretation memcpy(&some_int, ..., ...) is illegal,
> because memcpy() will write to the int's storage with a pointer type
> other than int.
Your conclusion does not follow since the standard does not say what (if
any) pointer type memcpy() will use internally. It is not even necessary
that memcpy() is implemented in C.
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se