Elements in an array are always stored in the expected [increasing] order, regardless of the endianess of the architecture. Moreover, due to the alignment rules, all members in a union will start at the same address.
It turns out there is no endianess conversion on the keys, so I suppose both peers have to somehow reach a consensus outside the PML.
On Nov 8, 2011, at 08:57 , Nathan T. Hjelm wrote:
> Sure, I can do that. My only concern is with sending between hosts of
> different endianness.
> For example, if seg_key is 128 bits wide and the key32 is 64 bits then we
> might run into this:
> Host 1: (big endian)
> Set seg_key.key32 = 0x11111111
> would result in seg_key: 0x00000000 0x00000000 0x11111111 0x00000000
> Host 2: (little endian)
> Set seg_key.key32 = 0x111111111
> would result in seg_key: 0x11111111 0x00000000 0x00000000 0x00000000
> If either host were to send the other one its seg_key and try to use the
> key32 they would get garbage. I haven't tested this case yet but I can test
> on a PPE of RR later today.
> On Tue, 8 Nov 2011 08:26:04 -0500, Jeff Squyres <jsquyres_at_[hidden]> wrote:
>> On Nov 7, 2011, at 9:48 PM, Nathan T. Hjelm wrote:
>>> In retrospect I should have done a RFC for the 3rd change with a short
>>> timeout. At the time (operating on little sleep) it seemed like the
>>> would have minimal impact. Please let me know if the commits have any
>>> negative impact.
>> FWIW, I think I'd like to see a rollback of the increase of array sizes
>> the seg_key union. They weren't necessary and might be slightly
>> Jeff Squyres
>> For corporate legal information go to:
>> devel mailing list
> devel mailing list