[
https://issues.apache.org/jira/browse/CASSANDRA-20190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17910675#comment-17910675
]
Dmitry Konstantinov edited comment on CASSANDRA-20190 at 1/7/25 4:49 PM:
-------------------------------------------------------------------------
I have also done a full text search for unsafe.put/get methods and found few
more places additionally to Memory and MemoryUtil:
*
org.apache.cassandra.utils.FastByteOperations.UnsafeOperations#compareTo(java.lang.Object,
long, int, java.lang.Object, long, int) - here we use unsafe.getLong to
speedup comparison but we use the same order for left and write here + we
assume that the array/byte buffer/native memory used here to compare has the
same order (I think big-endian) (/)
* test class: org.apache.cassandra.net.MessageGenerator#setId/getId - if I got
the logic correctly, technically it should be big endian order here instead of
native because we work with a network message content but it does not cause a
problem if all emulation is happen on a single host (!)
was (Author: dnk):
I have also done a full text search for unsafe.put/get methods and found few
more places additionally to Memory and MemoryUtil:
*
org.apache.cassandra.utils.FastByteOperations.UnsafeOperations#compareTo(java.lang.Object,
long, int, java.lang.Object, long, int) - here we use unsafe.getLong to
speedup comparison but we use the same order for left and write here + we
assume that the array/byte buffer/native memory used here to compare has the
same order (I think big-endian)
* test class: org.apache.cassandra.net.MessageGenerator#setId/getId - if I got
the logic correctly, technically it should be big endian order here instead of
native because we work with a network message content but it does not cause a
problem if all emulation is happen on a single host.
> MemoryUtil.setInt/getInt and similar use the wrong endianness
> -------------------------------------------------------------
>
> Key: CASSANDRA-20190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20190
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Local/Other
> Reporter: Branimir Lambov
> Priority: Normal
>
> `NativeCell`, `NativeClustering` and `NativeDecoratedKey` use the above
> methods from `MemoryUtil` to write and read data from native memory. As far
> as I can see they are meant to write data in big endian. They do not (they
> always correct to little endian).
> Moreover, they disagree with their `ByByte` versions on big-endian machines
> (which is only likely an issue on aligned-access architectures (x86 and arm
> should be fine)).
> The same is true for the methods in `Memory`, used by compression metadata as
> well as index summaries.
> We need to verify that this does not cause any problems, and to change the
> methods to behave as expected and document the behaviour by explicitly using
> `ByteOrder.LITTLE_ENDIAN` for any data that may have been persisted on disk
> with the wrong endianness.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
