My comment is about the definition of HAVE_UINTPTR_T in Rconfig.h. stdint.h is coming with (g)libc, therefore unlikely to change/appear/disappear (unless kernel and a bit of the OS changes), therefore may not be a realistic concern. On the other hand mixing compilers is frequent, but this is not doing much to prevent it.
2017-01-01 19:42 GMT-05:00 Simon Urbanek <simon.urba...@r-project.org>: > > > On Jan 1, 2017, at 5:12 PM, Laurent Gautier <lgaut...@gmail.com> wrote: > > > > > > > > 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <rip...@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 <lgaut...@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, rip...@stats.ox.ac.uk > > Emeritus Professor of Applied Statistics, University of Oxford > > > > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel