Prof Brian Ripley
ripley @ending from @t@t@@ox@@c@uk
Thu Aug 16 20:30:55 CEST 2018
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, 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
>> (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
> 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
More information about the R-devel