From edd @ending from debi@n@org  Thu Aug 16 14:12:22 2018
From: edd @ending from debi@n@org (Dirk Eddelbuettel)
Date: Thu, 16 Aug 2018 07:12:22 -0500
Subject: [Rd] longint
In-Reply-To: <7238fd29-6008-c32a-2446-8b6f534b77fd@gmail.com>
References: <b8cc39c0-2e5b-2157-173b-7341ab687188@gmail.com>
 <2f3f2125-2cb1-51b8-a5ec-9986a18e698b@gmail.com>
 <B6423F6B-A085-444B-9119-6B09B9349F78@stats.ox.ac.uk>
 <1608bafb-374d-1953-7694-de44e3ce9007@fredhutch.org>
 <7238fd29-6008-c32a-2446-8b6f534b77fd@gmail.com>
Message-ID: <23413.27174.647572.685196@rob.eddelbuettel.com>


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.

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

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org



[Rd] longint
Dirk Eddelbuettel