Near the beginning of src/types.jl the SxpPtrInfo type is defined as UInt32. I think that is out of date. Current versions of the "R Internals" manual state
Both types of node structure have as their first three fields a 64-bit sxpinfo header and then three pointers (to the attributes and the previous and next node in a doubly-linked list), and then some further fields.
I believe that things work out because the manipulations of later fields, like attributes, and getting data pointers (dataptr) are performed through calls to C functions in libR.
I can try out changing this to UInt64 and seeing if anything breaks but I first to ask if others understand the R Internals document the same way I do.
(If I am right, then RCall.jl will fail on big-endian systems because the SEXPTYPE code is in the first five bytes of the SxpPtrInfo. These happen to be in the same position on little-endian systems for UInt32 and UInt64, but not on big-endian systems. And if you are asking yourself, "Why would anyone care about big-endian systems? No one uses them." then you obviously haven't submitted a large, complex package to CRAN.)
Near the beginning of
src/types.jltheSxpPtrInfotype is defined asUInt32. I think that is out of date. Current versions of the "R Internals" manual stateI believe that things work out because the manipulations of later fields, like attributes, and getting data pointers (
dataptr) are performed through calls to C functions in libR.I can try out changing this to
UInt64and seeing if anything breaks but I first to ask if others understand the R Internals document the same way I do.(If I am right, then RCall.jl will fail on big-endian systems because the SEXPTYPE code is in the first five bytes of the SxpPtrInfo. These happen to be in the same position on little-endian systems for UInt32 and UInt64, but not on big-endian systems. And if you are asking yourself, "Why would anyone care about big-endian systems? No one uses them." then you obviously haven't submitted a large, complex package to CRAN.)