[GitHub] [arrow-nanoarrow] lidavidm commented on a diff in pull request #162: fix(extensions/nanoarrow_ipc): Ensure tests pass on big endian

["lidavidm (via GitHub)" <gi...@apache.org>]

lidavidm commented on code in PR #162:
URL: https://github.com/apache/arrow-nanoarrow/pull/162#discussion_r1140506306


##########
extensions/nanoarrow_ipc/src/nanoarrow/nanoarrow_ipc_test.cc:
##########
@@ -44,6 +49,18 @@ struct ArrowIpcDecoderPrivate {
 };
 }
 
+static enum ArrowIpcEndianness ArrowIpcSystemEndianness(void) {
+  uint32_t check = 1;
+  char first_byte;
+  enum ArrowIpcEndianness system_endianness;

Review Comment:
   unused?



##########
extensions/nanoarrow_ipc/src/nanoarrow/nanoarrow_ipc_test.cc:
##########
@@ -272,9 +297,16 @@ TEST(NanoarrowIpcTest, NanoarrowIpcDecodeSimpleRecordBatch) {
   ASSERT_EQ(array.children[0]->length, 3);
   EXPECT_EQ(array.children[0]->null_count, 0);
   const int32_t* out = reinterpret_cast<const int32_t*>(array.children[0]->buffers[1]);
-  EXPECT_EQ(out[0], 1);
-  EXPECT_EQ(out[1], 2);
-  EXPECT_EQ(out[2], 3);
+
+  if (ArrowIpcSystemEndianness() == NANOARROW_IPC_ENDIANNESS_LITTLE) {
+    EXPECT_EQ(out[0], 1);
+    EXPECT_EQ(out[1], 2);
+    EXPECT_EQ(out[2], 3);
+  } else {
+    EXPECT_EQ(out[0], bswap32(1));

Review Comment:
   Hmm, because the hardcoded data is in little-endian?
   
   Wonder if it would instead make sense to compare byte slices directly instead of int32_t values then



-- 
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: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org