lkml.org 
[lkml]   [2001]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Compatibility issue with 2.2.19pre7
Andrea Arcangeli <andrea@suse.de>:
> On Tue, Jan 23, 2001 at 11:51:15PM -0800, Richard Henderson wrote:
> > On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
> > > What I said is that I can write this C code:
> > >
> > > int x[2], * p = (int *) (((char *) &x)+1);
> > > main()
> > > {
> > > *p = 0;
> > > }
> > >
> > > This is legal C code.
> >
> > Err, no. This is not "legal" by any stretch of the imagination.
> > This code has undefined behaviour.
>
> I know this code has undefined behaviour at _runtime_. But I thought
> you were obliged to allow it to compile. That was my only point.
>
> > We aren't even obliged to allow this to compile.
>
> I'd love if you could forbid it to compile.

It would have to be implementation dependant/architecture dependant-
The only way to know is to realize that *p initializer value is invalid
is to know:

1. integer addresses MUST be aligned (say 4 or 8 byte boundaries)
2. the computation of (int *) (((char *) &x)+1) is a constant at
compile time, and not link time (some linkers can do address offset
calculations if "x" happens to be an external - ie. x +/- offset and
offset is a constant)

Other systems would have to allow it to compile (and link). It still has
undefined behaviour, and is non-portable.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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