stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject migrating tr1 headers for c++0x
Date Thu, 29 May 2008 00:45:59 GMT

I've run into a problem while migrating the cstdint/stdint.h headers to
their new home in the include/ansi directory for 4.3.x.

The idea is that I should move tr1/cstdint to ansi/_cstdint.h, and then
create ansi/cstdint to do the macro hackery like other similarly named
headers there. This is done to prevent us from providing types and
values that are inconsistent with what is expected by users or other
system headers.

Sadly I'm running into problems with the definition of ansi/cstdint on
Linux [and possibly other platforms]. On Linux the important macros are
defined as

  //#define _RWSTD_NO_PURE_C_HEADERS      1
  #define _RWSTD_ANSI_C_STDINT_H          "/usr/include/stdint.h"

Here is the body of my new ansi/cstdint header-

#include <rw/_defs.h>

#  include <ansi/_cstdint.h>







}   // namespace std

#endif   // _RWSTD_NAMESPACE_STD_OPEN == 19

#else   // if defined (_RWSTD_NO_DEPRECATED_C_HEADERS)



#if    !defined (_RWSTD_NO_NAMESPACE) \
    && !defined (_RWSTD_NO_HONOR_STD) \
    && !defined (_RWSTD_NO_USING_LIBC_IN_STD)

namespace std {

#ifdef _RWSTD_INT8_T
    using ::int8_t;
#endif   // _RWSTD_INT8_T


}   // std

#endif   //    !_RWSTD_NO_NAMESPACE
         // && !_RWSTD_NO_HONOR_STD
         // && !_RWSTD_NO_USING_LIBC_IN_STD




The problem is that the system /usr/include/stdint.h defines the
appropriate types [int8_t, uint8_t, ...], but it only defines the limit
macros [PTRDIFF_MAX, ...] if compiling as C or if __STDC_LIMIT_MACROS is
defined. So we get into the final block, include the system header, but
none of the macros come through. At the very least this causes a bunch
of failed assertions in the test, but due to some minor issues with the
test it actually fails to compile when these macros aren't defined.

Now I could easily just #define __STDC_LIMIT_MACROS for gcc before
including /usr/include/stdint.h [or in rw/_config-gcc.h], but that
wouldn't help much if the user included the system header before our

The other option is to put things back the way they were and always use
our definitions from ansi/cstdint. But then there is the possibility
that we would define a type or macro differently than the system include
does, which is what we were trying to avoid in the first place.

What do you think?


View raw message