[Rd] Definition of uintptr_t in Rinterface.h

[Laurent Gautier]

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.urbanek at r-project.org>:

>
> > 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
> >
>
>

	[[alternative HTML version deleted]]