Re: [boost] boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR

Subject: Re: [boost] boost/cstdint.hpp definition of INTMAX_C conflicts with MPFR
From: Vincent Lefevre (vincent_at_[hidden])
Date: 2010-02-15 16:20:16

On 2010-02-15 17:17:57 -0000, John Maddock wrote:
> >The reason is that mpfr.h supports systems with and without intmax_t
> >(so that it does not force <stdint.h> inclusion), thus it must have
> >a way to determine when intmax_t is available, without requiring the
> >user to do anything else than including <stdint.h> first. So, it has
> >several heuristics, one of them being the test of the existence of
> >INTMAX_C and UINTMAX_C. Indeed, in C, which does not have namespaces,
> >it is rather intuitive that the existence of INTMAX_C and UINTMAX_C
> >implies that the corresponding types intmax_t and uintmax_t are
> >available. However, in C++ with Boost, intmax_t and uintmax_t are
> >not necessarily available (in the global namespace).
> 
> Hmm, how can you use INTMAX_C to check for the existance of stdint.h
> when INTMAX_C is *defined in stdint.h*.

Perhaps I wasn't clear enough: if the user wants to use intmax_t, he
needs to make it available explicitly by including <stdint.h> before
mpfr.h (see below). Then INTMAX_C gets defined (in C).

> Note also that historically C++ systems have not defined INTMAX_C
> when including stdint.h (or any other header) unless a specific
> "magic macro" is defined (__STDC_CONSTANT_MACROS).

Yes, this is documented in the MPFR manual, as some users use a C++
compiler even to compile C programs. So, for better portability, a
user should do:

#if defined(__cplusplus)
# define __STDC_CONSTANT_MACROS
#endif
#include <stdint.h>
#include <mpfr.h>

That's at least for C programs. Now, specifically for C++ programs...

> Which brings us on to C++0x and the next C++ std.  In there INTMAX_C
> is always defined after including <cstdint>, but there is no
> intmax_t in global namespace (only namespace std) - it's this
> behaviour that Boost's stdint.hpp is trying to emulate.  We're also
> not alone in this - for example ICU will define some of the INT#_C
> macros if they're not already supplied.  And finally... the
> behaviour was introduced in response to user requests/bug reports,
> so I don't think we'll change, sorry!

I don't think there are much problems with the next C++ standard.
We don't know very much about users who use MPFR with their C++
programs, but I think that in practice, such users who want the
stdint types always include <stdint.h> as documented in the MPFR
manual, and in this case, intmax_t is available in the global
namespace, according to <http://en.wikipedia.org/wiki/Stdint.h>.

The problem is with systems that don't have a <stdint.h> header.
On such systems at least, Boost can now break MPFR. But I think
that if mpfr.h is included *before* C++/Boost-related headers,
then everything should work fine, because when the MPFR test on
INTMAX_C occurs, this macro hasn't been defined yet by Boost or
other C++-related headers.

> BTW Doesn't mpfr already use an autoconf script for configuration?

The autoconf script is used to build the MPFR library, not for using
the MPFR library in external programs. Moreover the mpfr.h file is
the same for all platforms (it is not generated[*]). That's why MPFR
functions that have (u)intmax_t as an argument or return type should
be declared in mpfr.h only if (u)intmax_t is available.

[*] We probably wouldn't like to do that anyway, as the conventional
tools are not designed for architecture-dependent headers files.

-- 
Vincent Lefèvre <vincent_at_[hidden]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)