> On Wed, May 18, 2005 at 05:31:55PM +0100, Daniel Barlow wrote:
> > Nikodemus Siivola <nikodemus=40random-state.net> writes:
> > >> this are some small fixes I made to get x86-arch.c compile with gc=
> > >> As all tests get passed, I think I didn't break it...
> > >
> > >> =21 ( (char*)(*os_context_pc_addr(context)) )++;
> > >
> > > changing to
> > >
> > >> =21 (*os_context_pc_addr(context)) +=3D sizeof(char);
> > >
> > > Um, is this just gcc-4.0 brokenness, or is there an actual correctn=
> > > issue here. As far as I can tell the first one is quite legal -- no=
> > > that I've though either long or deep about it.
> > I've not reviewed this code recently, but my memory is that in that
> > situation we really /do/ want to increment by one octet. That said,
> > my understanding is also that sizeof(char) is by definition 1 in C
> > anyway, so I really don't understand the goal of this change. Did
> > this change in C99 or something?
> As far as I can tell, what the original code made work were a gcc
> extension called =22cast-as-lvalue=22 which was deprecated in 3.3.4 and=
> 3.4 and now finally removed <http://gcc.gnu.org/gcc-4.0/changes.html>
> So it seems it never were ansi C code -- but I'm no expert in that
> kind of esoteric standard stuff..
> Anyway it's true, that sizeof(char) is one by definition, and maybe it
> should be replaced by it (the compiler will do it anyway) -- the
> reason I wrote it that way, was to preserve the semantics of the
> original code. :-)
Well, adding to (or incrementing) a pointer in C will take it to an align=
suitable for the next value of whatever type the pointer is.
So, if we have a pointer, whose value is 0 and it's a char*, adding 1 wil=
result in it pointing at 1. If it's a pointer to a 16-bit integer, it wil=
pointing at 2. For a 32-bit pointer, it wil be pointing at 4. For a point=
a struct taking 256 bytes, it will (most probably) be 256.
So, if the original intent was to get a 1-byte offset from os_context_pc_=
the code as-changed-to will be, urm, amusingly broken, unless that is a c=
and if it were, just removing the cast from the original code would (prob=
To convince C programmers that the above-stated poinetr arithmetic rules =
correct, remember that a=5Bb=5D is defined as being *identical* to *(a+b)=
(for any pointer to an array a) a=5B0=5D is the first element, a=5B1=5D t=
he second and=20
so on, without overlap.