k8ika0s commented on PR #48219: URL: https://github.com/apache/arrow/pull/48219#issuecomment-3568376195
@Vishwanatha-HD Something I’ve bumped into on s390x is that the swap decision sometimes needs to follow the *encoded* byte-order marker more closely than the compile-time `ARROW_LITTLE_ENDIAN` macro. A couple of the downstream readers (especially in geospatial stats) assume “LE on disk” is its own concept, even if the host is BE. So I’m curious how this change behaves when the host is big-endian but the consuming path is trying to normalize everything toward a canonical LE interpretation. On the level-bitmap side, I’ve occasionally seen the bitmap comparison logic behave differently depending on whether the input originated on a BE machine or came directly from Arrow buffers that were already LE-canonical. Wrapping `GreaterThanBitmap` with a swap might be exactly what’s needed here — I’m mostly wondering how consistently the upstream paths feed this comparison LE vs. host-order data. Not flagging this as wrong; just passing along some of the odd little behaviors I’ve seen on the BE side of things. Happy to help run this through a few combinations on actual s390x hardware if that would be useful. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
