[Rd] longint

[Hervé Pagès]

On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote:
> 
> On 15 August 2018 at 20:32, Benjamin Tyner wrote:
> | Thanks for the replies and for confirming my suspicion.
> |
> | Interestingly, src/include/S.h uses a trick:
> |
> |     #define longint int
> |
> | and so does the nlme package (within src/init.c).
> 
> As Bill Dunlap already told you, this is a) ancient and b) was concerned with
> the int as 16 bit to 32 bit transition period. Ie a long time ago. Old C
> programmers remember.
> 
> You should preferably not even use 'long int' on the other side but rely on
> the fact that all compiler nowadays allow you to specify exactly what size is
> used via int64_t (long), int32_t (int), ... and the unsigned cousins (which R
> does not have).  So please receive the value as a int64_t and then cast it to
> an int32_t -- which corresponds to R's notion of an integer on every platform.

Only on Intel platforms int is 32 bits. Strictly speaking int is only
required to be >= 16 bits. Who knows what the size of an int is on
the Sunway TaihuLight for example ;-)

H.

> 
> And please note that that conversion is lossy.  If you must keep 64 bits then
> the bit64 package by Jens Oehlschlaegel is good and eg fully supported inside
> data.table. We use it for 64-bit integers as nanosecond timestamps in our
> nanotime package (which has some converters).
> 
> Dirk
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages using fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319