Endianness of padded scalar objects
in [Visual C]
|
From: Ulrich Eckhardt on 25 Feb 2010 10:41 David Lowndes wrote: >>> I wouldn't expect sizeof to include the alignment padding - so the >>> problem you're envisaging with the padding shouldn't exist. >> >>I would. Imagine this code: >> >> T t0; >> T t1[1]; >> T t2[2]; >> assert((sizeof t0) == (sizeof t1)); >> assert((2 * sizeof t0) == (sizeof t2)); >> >>The reported size must include the padding for alignment there. > > You've lost me there Uli - the results of that are way I'd expect (no > padding issues). Show us a complete example that illustrates the > problem. Okay.... Let's assume a fictional long double type that is 12 bytes large. However, it doesn't need a 12-byte alignment but actually a 16-byte alignment because the FPU says so. Now, you said "I wouldn't expect sizeof to include the alignment padding", so for that type you would expect sizeof(long double) to yield 12, right? However, I would expect it to include that padding and yield 16 instead. The reason is simply that the layout of an object (i.e. the size it occupies including padding) should be the same, regardless of whether it was allocated alone or in an array. If it didn't, you couldn't e.g. compute the number of elements in an array with (sizeof array)/(sizeof array[0]) any more. Uli -- C++ FAQ: http://parashift.com/c++-faq-lite Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
From: David Lowndes on 25 Feb 2010 11:25 >Let's assume a fictional long double type that is 12 bytes large. However, >it doesn't need a 12-byte alignment but actually a 16-byte alignment >because the FPU says so. I could argue that in essence that makes the type really 16 bytes though. I'm still not convinced by fictional things. Does anyone have a real example that would truly illustrate this? Dave
From: Bo Persson on 25 Feb 2010 12:45 David Lowndes wrote: >> Let's assume a fictional long double type that is 12 bytes large. >> However, it doesn't need a 12-byte alignment but actually a >> 16-byte alignment because the FPU says so. > > I could argue that in essence that makes the type really 16 bytes > though. > > I'm still not convinced by fictional things. Does anyone have a real > example that would truly illustrate this? > You had one previously .-) T t0; T t1[1]; T t2[2]; assert((sizeof t0) == (sizeof t1)); assert((2 * sizeof t0) == (sizeof t2)); The reported size must include the padding for alignment there. Array indexing is based on sizeof(element), as is pointer arithmetic. That's why the alignment cannot be different from the size of the array elements. Bo Persson
From: Bo Persson on 25 Feb 2010 12:53 Igor Tandetnik wrote: > Barry Schwarz <schwarzb(a)dqel.com> wrote: >> On Wed, 24 Feb 2010 18:06:30 -0500, "Igor Tandetnik" >> <itandetnik(a)mvps.org> wrote: >> >>> I don't know of any architecture where sizeof(long double) == 16, >>> let alone two of them that differ in endianness. If you know of >>> such machines, and you find yourself in an unenviable position of >>> having to exchange binary data between them, you should consult >>> their accompanying manuals, which hopefully would explain >>> precisely how those long double values are laid out. >> >> Try the entire IBM zArchitecture family > > Well, according to > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/download/A2278325.pdf?DT=20070807125005&XKS=DZ9ZBK07 > > page 19-2, this architecture does indeed provide for 16-byte-large > floating point numbers, but they don't have any padding inside - > all bytes are significant. Also, do z/Architecture machines come in > both little-endian and big-endian flavor? No, and the floating point format is proprietary anyway, so there is no need to transfer it anywhere else (in binary). Isn't the answer to the correct question: "Define a common format, and convert to and from that as needed at both ends."? Bo Persson
From: Igor Tandetnik on 25 Feb 2010 13:10
Bo Persson <bop(a)gmb.dk> wrote: > Isn't the answer to the correct question: "Define a common format, and > convert to and from that as needed at both ends."? Quite. For binary data exchange, may I suggest XDR? http://www.rfc-editor.org/rfc/rfc4506.txt XRD happens to closely follow the "usual" representation on a big-endian machine for most types. In many cases, all that's needed to convert between native and XDR representation is a judicial application of hton{l,s} and ntoh{l,s}. Thought those weird 16-byte doubles with internal padding will require special handling. -- With best wishes, Igor Tandetnik With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925 |