On 29/12/2016 15:55, Simon Urbanek wrote:
The problem is elsewhere - Rinterface.h guards the ultima-ratio fallback with
HAVE_UINTPTR_T but that config flag is not exported in Rconfig.h. Should be now
fixed in R-devel - please check if that works for you.
Rconfig.h would be appropriate if Rinterface.h is being included from C
code using the same compiler as used for R. But as Rinterface.h is
intended for use by alternative front ends there is no guarantee that
they use the same compiler (and some use C++).
This was documented in the manual:
'Note that uintptr_t is a C99 type for which a substitute is defined in
R, so your code needs to define HAVE_UINTPTR_T appropriately.'
AFAICS if you comply, there will not be a conflict.
Also note that is only an issue if CSTACK_DEFNS is defined, not the
default and not mentioned here.
Thanks,
Simon
On Dec 26, 2016, at 11:25 PM, Laurent Gautier <lgaut...@gmail.com> wrote:
Hi,
I was recently pointed out that a definition in Rinterface.h can be conflicting
with a definition in stdint.h:
/usr/include/R/Rinterface.h has:
typedef unsigned long uintptr_t;
/usr/include/stdint.h has:
typedef unsigned int uintptr_t;
(when 32bit platform complete definition is:
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned long int uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned int uintptr_t;
#endif
)
Is this expected ? Shouldn't R rely on the definition in stdint.h
But there need not be one in stdint.h, as the type is optional in
C99/C11/C++11 and likely not present in C++98.
rather than define its own ?
(report for the issue:
https://bitbucket.org/rpy2/rpy2/issues/389/failed-to-compile-with-python-360-on-32
)
Laurent
--
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
