[Rd] Definition of uintptr_t in Rinterface.h

[Simon Urbanek]

> On Jan 1, 2017, at 5:12 PM, Laurent Gautier <lgautier at gmail.com> wrote:
> 
> 
> 
> 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <ripley at stats.ox.ac.uk>:
> 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++).
> 
> Isn't the changing libc/glibc not recommended anyway (without also changing to a matching kernel) ? If so, is this a realistic concern compared to the compiler version issues (mentioned by Dirk) ? In that case, what about simplifying the documentation and usage to "use the same compiler or undefined behaviour may occur"
> 

Unfortunately people often mix up different compilers (note this has nothing to do with glibc or the kernel!) - mixing up C and C++ is very common. Also there are specialized compilers for some applications (MPI etc.). So, yes, it is a realistic concern that I've seen more often than you'd think.


> 
> 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 <lgautier at gmail.com> wrote:
> (...)
> 
> 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.
> 
> AFAIUI stdin.h is part of C99: https://en.wikipedia.org/wiki/C_standard_library#Header_files 
> 
> While at it, it is not exactly like C99 is the latest thing in town. Wouldn't relying on it give an opportunity to simplify the code base ?
> 
> 
> 
> 
> Laurent
> 
> 
> 
> 
> 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,                  ripley at stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>