Should we add an accessor for `integer64`?

[MichaelChirico]

Should we add an accessor for integer64?

#define INTEGER64_RO(x)	((const int64_t *) DATAPTR_RO(x))

Originally posted by @ben-schwen in #7611 (comment)

Makes high-level sense to avoid coming up with different ways of doing this throughout the codebase.

It should probably be paired with an INTEGER64(x) accessor too.

And possibly, this should be something exported by {bit64} itself, although we may not want LinkingTo {bit64}...

[aksh08022006]

I took a look through the codebase and found several places where integer64 data is accessed using direct casts such as (const int64_t *)DATAPTR_RO(x) and (int64_t *)DATAPTR(x). These appear in multiple files with slight variations, which seems to be the inconsistency this issue is pointing out.

Other core types (integer, real, logical, etc.) already have standardized accessor macros that improve readability and reduce the need for repeated casts. Following the same pattern, it seems reasonable to introduce something like:

#define INTEGER64_RO(x) ((const int64_t *) DATAPTR_RO(x)) #define INTEGER64(x) ((int64_t *) DATAPTR(x))

Placing these alongside the existing accessors (in the same header where INTEGER_RO, REAL_RO, etc. are defined) would keep the style consistent with the rest of the codebase.

This would allow replacing the scattered casts with a single standardized form and improve internal consistency without changing behavior.

If this direction makes sense, I’d be happy to prepare a PR that introduces the macros and updates the current usages accordingly.

[aitap]

DATAPTR is non-API and may eventually be removed. There's DATAPTR_RW introduced in R-devel, but it's only intended to be used in some rare ALTREP method implementations. Since integer64 vectors are stored in REALSXP vectors, we should probably be using REAL and REAL_RO to access their data pointers.