[boost] [Ticket #3548] Comeau C++ reports global scope has no int64_t

Subject: [boost] [Ticket #3548] Comeau C++ reports global scope has no int64_t
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2009-11-21 15:41:33

Hi,

I've been trying to diagnose and fix the problem with
missing definition of int64_t and uint64_t when using Comeau C/C++
frontend on Linux 32-bit with GCC 4.x.

I submitted all details to the Trac:

https://svn.boost.org/trac/boost/ticket/3548

Shortly, the problem is that if <sys/types.h> header is
included then <boost/cstdint.hpp> can't import uint64_t/int64_t types.
However, if <stdint.h> is used, everything works.

1) Does compile with Comeau + GCC

#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
}

2) 1) Does compile with Comeau + GCC as well

#include <stdint.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
}

3) Does not compile with Comeau + GCC

#include <sys/types.h>
#include <boost/cstdint.hpp>
int main()
{
    boost::int64_t a(0);
}

What I found is that there are slight differences, in GNU C Library,
in how those integer types are defined:

1) <sys/types.h>

#  elif __GLIBC_HAVE_LONG_LONG
__extension__ typedef long long int int64_t;
#  endif

2) <stdint.h>

# else
__extension__
typedef long long int		int64_t;
# endif

More details are in the #3548 ticket report.
Shortly, sys/types.h vs stdint.h are somewhat competing and seem to
confuse <boost/cstdint.hpp> definitions. Both headers define
__int8_t what disables the other definitions, thus depending on
which header goes first, that one wins but with different effect
regarding int64_t type.

I exchanged a few e-mails with Comeau team about it and, as for this
moment, we've concluded this slight differences between the two headers
seem a bit odd and competing indeed. Comeau team has been very helpful
and they are willing to make further investigation of this problem.

In the meantime, I decided to report this issue to GNU C Library
bugzilla (I should send to their mailing list first, my mistake):

http://sourceware.org/bugzilla/show_bug.cgi?id=10990

Ulrich Drepper confirmed that this is not GNU C Library issue:

"stdint.h is a C99 header and C99 demands the implementation of long
long. The headers are correct."

Fair enough. However, it makes it more difficult to me to understand
where fixes should go. So, I'd like to ask the Community here for
help in diagnosing this problem.

My thought for now is that if Boost Integer is used with Comeau C/C++
frontend with GCC, Boost configuration could detect if <sys/types.h>
was included first and try to disable its effects, like undefine
__int8_t and only let int64_t and uint64_t definitions
from  <stdint.h> header.

I believe that solving this problem is quite important to make Boost
compilable with Comeau C/C++ frontend, because, as far as I've tested,
it mostly leaks when compiling Boost.Test and tests of Boost libraries.

I'd be thankful for any thoughts on this.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org