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, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
