Re: [boost] alignment problem in proposed any alternative

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-08-11 10:17:23

Rob Stewart wrote:

> From: Martin Bonner <martin.bonner_at_[hidden]>
> > From: christopher diggins [mailto:cdiggins_at_[hidden]]
> > 
> > > 3.9(2) says:
> > > For any complete POD object type T, whether or not the object holds a
> > > valid value of type T, the underlying
> > > bytes (1.7) making up the object can be copied into an array of char
> > > or unsigned char.36) If the content of the array of char or unsigned
> > > char is copied back into the object, the object shall subsequently
> > > hold its original value.
> > > 
> > > This clearly implies char arrays are stringently aligned.
> > 
> > Err, no it doesn't.  It says that you can store the bits of a POD object
> > into a char array, and then load the bits back into the same (correctly
> > aligned) POD object.  
> > 
> > It does *NOT* say that you can use the address of the char array as if it
> > were the address of the POD object.
> 
> I also agree with this analysis of the text.

That's because it's correct, presumably  :)

> > #include <assert.h>
>   #include <string.h>
> > int main()
> > {
> > 	long pod = 3141L;
> > 	char pad;
> > 	char c[sizeof(pod)];
> > 	memcpy( c, &pod, sizeof(pod) );
> > 	pod = 42L;
> > 	memcpy( &pod, c, sizeof(pod) );
> > 	assert (pod == 3141L);	// 3.9(2) requires this assert to pass.
> > 	// nothing requires THIS assert to pass, and on some systems it fail
> > 	// because c is not suitable aligned.
> > 	assert ( *reinterpret_cast<long*>(&c[0]) == 3141L );
> >       return 0;
> > }
> 
> That fails on a Sun box.

It doesn't when I try it, but if you make the array one char bigger and
write to c+1, read from c+1 and cast c[1] then it fails everytime with a
bus error.  Or see the example I sent, which fails every time on sparc.

jon