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*. 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). 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! BTW Doesn't mpfr already use an autoconf script for configuration? If so isn't it trivial to check for that header in that? HTH, John.