hey Micah, On Mon, Aug 1, 2016 at 11:02 AM, Micah Kornfield <emkornfi...@gmail.com> wrote: > Hi Wes, > The point I was trying to argue from an earlier thread is that the most > common cases for relocation are: > 1. Little endian machine to little endian machine (most likely same > machine) > 2. big endian machine to big endian machine (most likely same machine) > 3. big endian machine to little endian machine or vice versa > > The purpose of the metadata would be to make use-cases 1 and 2 possible > without byte-swapping. Use case 3 would obviously require byte swapping > but for an initial implementation the code could simply indicate that it is > not supported. > > This seems less complex to me than actually implementing any sort of > byte-swapping logic while still supporting the widest variety of hardware > with the same code for the most common use-cases.
This makes sense. My comments were for the situation that a big endian system would be exposing memory to an unknown consumer -- for example, if we implemented an RPC wire format for Arrow memory, then in general a big endian system would need to send little-endian integers to an arbitrary receiver. I'm not sure the best way to provide for easy native-endianness support for cases 1/2, but trying to fully solve this problem now seems premature until we've established some of these tools (so long as we haven't painted ourselves into a corner). - Wes > > Thanks, > Micah > > P.S. If anybody can provide pointers I'd be interested to understand which > pieces of the java code make assumptions about little-endianness.
