lkml.org 
[lkml]   [2003]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Invalid compilation without -fno-strict-aliasing
On Wed, Feb 26, 2003 at 05:47:48PM -0300, Horst von Brand wrote:
> Falk Hueffner <falk.hueffner@student.uni-tuebingen.de> said:
> > Horst von Brand <vonbrand@inf.utfsm.cl> writes:
> > > Jean Tourrilhes <jt@bougret.hpl.hp.com> said:
> > > > if((stream + event_len) < ends) {
> > > > iwe->len = event_len;
> > > > memcpy(stream, (char *) iwe, event_len);
> > > > stream += event_len;
> > > > }
> > > > return stream;
> > > > }
> > >
> > > The compiler is free to assume char *stream and struct iw_event *iwe
> > > point to separate areas of memory, due to strict aliasing.
> >
> > The relevant paragraph of the C99 standard is:
> >
> > An object shall have its stored value accessed only by an lvalue
> > expression that has one of the following types:
> [...]
> > -- a character type.
>
> (char *) gives you a (pointer to) a character type.
>
> > I can't really spot any lvalue here that might violate this rule. It
> > would be nice if somebody could report a bug with a testcase.
>
> stream and (char *) iwe

Stream is not the same storage as iwe, so this is hardly the issue.
Writes to stream don't affect iwe. The problem was the assignment to
iwe->len being moved after the access, according to the report.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:33    [W:0.049 / U:1.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site