Definition of uintptr_t in Rinterface.h

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Definition of uintptr_t in Rinterface.h

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

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

Simon Urbanek
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.

Thanks,
Simon



> On Dec 26, 2016, at 11:25 PM, Laurent Gautier <[hidden email]> 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
> 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
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

lgautier
Thanks for looking at it. Having  HAVE_UINTPTR_T defined in Rconfig.h
should fix the issue. Will the fix make it to R-3.3.3 (if that point
release is planned, or R-3.3.2-patched), or will it only be with R-3.4 ?


L.

PS: I am forwarding a thank you note to the reporter of the problem on the
rpy2 issue tracker.


2016-12-29 10:55 GMT-05:00 Simon Urbanek <[hidden email]>:

> 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.
>
> Thanks,
> Simon
>
>
>
> > On Dec 26, 2016, at 11:25 PM, Laurent Gautier <[hidden email]>
> 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
> > 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
> >
> >       [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > [hidden email] mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

Prof Brian Ripley
In reply to this post by Simon Urbanek
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 <[hidden email]> 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,                  [hidden email]
Emeritus Professor of Applied Statistics, University of Oxford

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

Dirk Eddelbuettel

On 1 January 2017 at 13:28, Prof Brian Ripley wrote:
| 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.

Relatedly: Any good way about "using the same compiler as used for R"?

I write one package exposing some internal R API for wider use
in a package (RApiSerialize, used eg by RcppRedis) and like that scheme. I
might do the same for date/time/timezone logic but this hinges on these
settings (among other things).

Any good ideas how to go about this?  So far I mostly use 'don't ask don't
tell' and rely on the compiler to actually fail when something doesn't hold.
We can probably do better...

Best wishes to all useRs and devRs in 2017.

Dirk

--
http://dirk.eddelbuettel.com | @eddelbuettel | [hidden email]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

lgautier
In reply to this post by Prof Brian Ripley
2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <[hidden email]>:

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


> 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 <[hidden email]> 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,                  [hidden email]
> Emeritus Professor of Applied Statistics, University of Oxford
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

Simon Urbanek

> On Jan 1, 2017, at 5:12 PM, Laurent Gautier <[hidden email]> wrote:
>
>
>
> 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <[hidden email]>:
> 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 <[hidden email]> 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,                  [hidden email]
> Emeritus Professor of Applied Statistics, University of Oxford
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Definition of uintptr_t in Rinterface.h

lgautier
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 <[hidden email]>:

>
> > On Jan 1, 2017, at 5:12 PM, Laurent Gautier <[hidden email]> wrote:
> >
> >
> >
> > 2017-01-01 8:28 GMT-05:00 Prof Brian Ripley <[hidden email]>:
> > 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 <[hidden email]>
> 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,                  [hidden email]
> > Emeritus Professor of Applied Statistics, University of Oxford
> >
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel