[Rd] longint

[Prof Brian Ripley]

On 16/08/2018 18:33, Hervé Pagès wrote:
> 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 

Well, not all compilers.  Those types were introduced in C99, but are 
optional in that standard and in C11 and C++11.  I have not checked 
C++1[47], but expect they are also optional there.  int_fast64_t is not 
optional in C99, so R uses that if int64_t is not supported.

[It is easy to overlook that they are optional in C99 and at one time R 
assumed them.]

>> (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 ;-)

R's configure checks that int is 32 bit and will not compile without it 
(src/main/arithmetic.c) ... so int and int32_t are the same on all 
platforms where the latter is defined.

-- 
Brian D. Ripley,                  ripley using stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford