Re: [boost] alignment problem in proposed any alternative
----Original Message---- From: christopher diggins [mailto:cdiggins@videotron.ca] Sent: 11 August 2005 14:00 To: boost@lists.boost.org Subject: Re: [boost] alignment problem in proposed any alternative [snip]
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 has nothing to do with void* and char*, but rather with all POD's.
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. For example: #include <assert.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; } -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
From: Martin Bonner <martin.bonner@pitechnology.com>
From: christopher diggins [mailto:cdiggins@videotron.ca]
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.
#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. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Martin Bonner <martin.bonner@pitechnology.com>
From: christopher diggins [mailto:cdiggins@videotron.ca]
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
----- Original Message ----- From: "Martin Bonner" <martin.bonner@pitechnology.com> To: <boost@lists.boost.org> Sent: Thursday, August 11, 2005 9:22 AM Subject: Re: [boost] alignment problem in proposed any alternative
----Original Message---- From: christopher diggins [mailto:cdiggins@videotron.ca] Sent: 11 August 2005 14:00 To: boost@lists.boost.org Subject: Re: [boost] alignment problem in proposed any alternative
[snip]
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 has nothing to do with void* and char*, but rather with all POD's.
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.
For example: #include <assert.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; }
Thank you for correcting me clearly and politely. Christopher Diggins
participants (4)
-
christopher diggins -
Jonathan Wakely -
Martin Bonner -
Rob Stewart