This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC aliasing rules: more aggressive than C99?


Erik Trulsson <ertr1013 <at> student.uu.se> writes:
> On Mon, Jan 04, 2010 at 08:17:00PM +0000, Joshua Haberman wrote:
> > 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.5 does define circumstances under which converted pointers may
be dereferenced.  Section 6.3.2.3 does not include any language
prohibiting it, so it does not support the assertion it was quoted to
support, and it is irrelevant in the context of this discussion.

> > > [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.

It says that it will copy characters.  More importantly, you are still 
ignoring section 6.5 without saying why.

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]