bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed


From: Jarno Rajahalme
Subject: Re: Gnulib 64-bit ABI bug with OSX, generic patch proposed
Date: Tue, 20 Apr 2010 12:26:04 -0700

This in the gnulib stdint.h:

/* Get those types that are already defined in other system include
   files, so that we can "#define int8_t signed char" below without
   worrying about a later system include file containing a "typedef
   signed char int8_t;" that will get messed up by our macro.  Our
   macros should all be consistent with the system versions, except
   for the "fast" types and macros, which we recommend against using
   in public interfaces due to compiler differences.  */

So it seems that the aim is for the gnulib/stdint.h types and the macros be 
consistent with the system versions. If so, why not use the system versions for 
defining them, if they exist? Or is this existence check hard to do universally 
right?

For example, OSX defines _INT64_T to mark the typedef for int64_t, but there is 
no corresponding marker for the uint64_t.

The above aim for consistency does not currently hold, whenever the native 
int64_t is "long long" or "long long int", and uint64_t is "unsigned long long" 
or "unsigned long long int". In these cases the current definitions of the 
corresponding macros (int64_t and uint64_t) in gnulib/stdint.h break the ABI.

I do not know if other systems than OSX are affected, but this needs to be 
fixed. Current definitions already have special cases for specific 
environments, so I would start with this:

--- a/lib/stdint.in.h
+++ b/lib/stdint.in.h
@@ -135,7 +135,8 @@ typedef unsigned int gl_uint32_t;
 
 /* Do not undefine int64_t if gnulib is not being used with 64-bit
    types, since otherwise it breaks platforms like Tandem/NSK.  */
-#if LONG_MAX >> 31 >> 31 == 1
+/* OSX needs int64_t to be "long long" rather than "long int" */
+#if LONG_MAX >> 31 >> 31 == 1 && !(defined (__APPLE__) && defined (__MACH__))
 # undef int64_t
 typedef long int gl_int64_t;
 # define int64_t gl_int64_t
@@ -152,7 +153,8 @@ typedef long long int gl_int64_t;
 # define GL_INT64_T
 #endif
 
-#if ULONG_MAX >> 31 >> 31 >> 1 == 1
+/* OSX needs uint64_t to be "long long" rather than "long int" */
+#if ULONG_MAX >> 31 >> 31 >> 1 == 1 && !(defined (__APPLE__) && defined 
(__MACH__))
 # undef uint64_t
 typedef unsigned long int gl_uint64_t;
 # define uint64_t gl_uint64_t


More elegant solutions could be done later, if need be. One would be to test 
the presence of the corresponding typedefs at configure time and then not 
redefine them, if they exist already.

Regards,

  Jarno


On Apr 16, 2010, at 3:59 PM, ext Paolo Bonzini wrote:

> On 04/17/2010 12:12 AM, Jarno Rajahalme wrote:
>> With this patch the ABI compatibility is maintained, and linking
>> succeeds.
> 
> It would likewise start to fail on Linux, though.
> 
>> maybe a configure time check for int64_t is needed.
> 
> Yes.  Already defined types should not be redefined.
> 
> Paolo
> 
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]