bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Jan Djärv]

Hi.

Somewhere in gnulib, intmax_t gets defined to int64_t thus causing
compiler warnings and general confusion (the code says intmax_t but is
really int64_t).  AFAIK, all versions of OSX have intmax_t.

	Jan D.


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/Users/jhd/bin/Emacs.app/Contents/Resources/etc/DEBUG.


In GNU Emacs 24.0.50.1 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36)
  of 2011-07-08 on zeplin
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  '--verbose' '--enable-asserts' '--without-x' 
'--with-ns' 'CFLAGS=-g''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: C
   value of $LC_CTYPE: nil
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: sv_SE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   desktop-save-mode: t
   delete-selection-mode: t
   icomplete-mode: t
   display-time-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
<escape> x r e p o r t - e m <tab> <return>

Recent messages:
Loading /Users/jhd/lib/elisp/BAK-file.el (source)...done
Loading /Users/jhd/lib/elisp/ccsetup.el (source)...done
Loading icomplete...done
Loading desktop...done
No desktop file.
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug desktop cus-start cus-load msb delsel advice help-fns
advice-preload icomplete cc-mode cc-fonts easymenu cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt time
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process ns multi-tty emacs)

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Paul Eggert]

[Following up <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9025>
and cc'ing to bug-gnulib:]

Jan Djärv writes:

> Somewhere in gnulib, intmax_t gets defined to int64_t thus causing
> compiler warnings and general confusion (the code says intmax_t but is
> really int64_t).  AFAIK, all versions of OSX have intmax_t.

Thanks for reporting this.  I assume that intmax_t is 'long long'
whereas int64_t is 'long'?  If not, what are those two types defined
to in the system? and by gnulib?

Which compiler and OS version are you using?

Does the following (untested) patch to lib/stdint.in.h fix your problem?

diff --git a/lib/stdint.in.h b/lib/stdint.in.h
index c44401f..0dd60b9 100644
--- a/lib/stdint.in.h
+++ b/lib/stdint.in.h
@@ -270,6 +270,11 @@ typedef unsigned long int gl_uintptr_t;
 /* Note: These types are compiler dependent. It may be unwise to use them in
    public header files. */
 
+/* If the system defines INTMAX_MAX, assume that intmax_t works, and
+   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
+   assuming one type where another is used by the system.  */
+
+#ifndef INTMAX_MAX
 #undef intmax_t
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 typedef long long int gl_intmax_t;
@@ -280,7 +285,9 @@ typedef long long int gl_intmax_t;
 typedef long int gl_intmax_t;
 # define intmax_t gl_intmax_t
 #endif
+#endif
 
+#ifndef UINTMAX_MAX
 #undef uintmax_t
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 typedef unsigned long long int gl_uintmax_t;
@@ -291,6 +298,7 @@ typedef unsigned long long int gl_uintmax_t;
 typedef unsigned long int gl_uintmax_t;
 # define uintmax_t gl_uintmax_t
 #endif
+#endif
 
 /* Verify that intmax_t and uintmax_t have the same size.  Too much code
    breaks if this is not the case.  If this check fails, the reason is likely
@@ -431,8 +439,8 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
 
 /* 7.18.2.5. Limits of greatest-width integer types */
 
+#ifndef INTMAX_MAX
 #undef INTMAX_MIN
-#undef INTMAX_MAX
 #ifdef INT64_MAX
 # define INTMAX_MIN  INT64_MIN
 # define INTMAX_MAX  INT64_MAX
@@ -440,13 +448,15 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
 # define INTMAX_MIN  INT32_MIN
 # define INTMAX_MAX  INT32_MAX
 #endif
+#endif
 
-#undef UINTMAX_MAX
+#ifndef UINTMAX_MAX
 #ifdef UINT64_MAX
 # define UINTMAX_MAX  UINT64_MAX
 #else
 # define UINTMAX_MAX  UINT32_MAX
 #endif
+#endif
 
 /* 7.18.3. Limits of other integer types */
 

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Bruno Haible]

Jan Djärv writes:

> > Somewhere in gnulib, intmax_t gets defined to int64_t thus causing
> > compiler warnings and general confusion (the code says intmax_t but is
> > really int64_t).  AFAIK, all versions of OSX have intmax_t.

Please provide a reproducible test case, preferrably outside Emacs.

Also, I don't understand what's the problem: intmax_t must be 64-bit on
MacOS X. No compiler supports 128-bit integers, AFAIK. Can you explain?

Paul Eggert wrote:
> Which compiler and OS version are you using?
> 
> Does the following (untested) patch to lib/stdint.in.h fix your problem?
> 
> diff --git a/lib/stdint.in.h b/lib/stdint.in.h
> index c44401f..0dd60b9 100644
> --- a/lib/stdint.in.h
> +++ b/lib/stdint.in.h
> @@ -270,6 +270,11 @@ typedef unsigned long int gl_uintptr_t;
>  /* Note: These types are compiler dependent. It may be unwise to use them in
>     public header files. */
>  
> +/* If the system defines INTMAX_MAX, assume that intmax_t works, and
> +   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
> +   assuming one type where another is used by the system.  */
> +
> +#ifndef INTMAX_MAX
>  #undef intmax_t
>  #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
>  typedef long long int gl_intmax_t;
> @@ -280,7 +285,9 @@ typedef long long int gl_intmax_t;
>  typedef long int gl_intmax_t;
>  # define intmax_t gl_intmax_t
>  #endif
> +#endif

Untested patches are OK in simple areas. But in complex areas like stdint.in.h
I would really like to understand the problem before applying any patch. That
means, provide a reproducible sample (including all details about OS, compiler,
compiler options), and show the preprocessing result (output of "$CC -E" or
- even better - "$CC -E -dD") of the code that gives warnings.

Bruno
-- 
In memoriam Báb <http://en.wikipedia.org/wiki/Báb>

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Jan Djärv]

Paul Eggert skrev 2011-07-09 12.01:
> [Following up<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9025>
> and cc'ing to bug-gnulib:]
>
> Jan Djärv writes:
>
>> Somewhere in gnulib, intmax_t gets defined to int64_t thus causing
>> compiler warnings and general confusion (the code says intmax_t but is
>> really int64_t).  AFAIK, all versions of OSX have intmax_t.
>
> Thanks for reporting this.  I assume that intmax_t is 'long long'
> whereas int64_t is 'long'?  If not, what are those two types defined
> to in the system? and by gnulib?

/usr/include/stdint.h:

typedef long long            int64_t;

and

#ifndef _INTMAX_T
#define _INTMAX_T
#ifdef __INTMAX_TYPE__
typedef __INTMAX_TYPE__             intmax_t;
#else /* __INTMAX_TYPE__ */
typedef long long                intmax_t;
#endif /* __INTMAX_TYPE__ */
#endif /* _INTMAX_T */

I don't know where __INTMAX_TYPE__ is defined, but looking at preprocessed 
output gives:

typedef long int intmax_t;


>
> Which compiler and OS version are you using?

% gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking 
--enable-werror --prefix=/usr --mandir=/share/man 
--enable-languages=c,objc,c++,obj-c++ 
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib 
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- 
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10 
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)

OSX 10.6.8.


>
> Does the following (untested) patch to lib/stdint.in.h fix your problem?

Yes it does.

	Jan D.

>
> diff --git a/lib/stdint.in.h b/lib/stdint.in.h
> index c44401f..0dd60b9 100644
> --- a/lib/stdint.in.h
> +++ b/lib/stdint.in.h
> @@ -270,6 +270,11 @@ typedef unsigned long int gl_uintptr_t;
>   /* Note: These types are compiler dependent. It may be unwise to use them in
>      public header files. */
>
> +/* If the system defines INTMAX_MAX, assume that intmax_t works, and
> +   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
> +   assuming one type where another is used by the system.  */
> +
> +#ifndef INTMAX_MAX
>   #undef intmax_t
>   #if @HAVE_LONG_LONG_INT@&&  LONG_MAX>>  30 == 1
>   typedef long long int gl_intmax_t;
> @@ -280,7 +285,9 @@ typedef long long int gl_intmax_t;
>   typedef long int gl_intmax_t;
>   # define intmax_t gl_intmax_t
>   #endif
> +#endif
>
> +#ifndef UINTMAX_MAX
>   #undef uintmax_t
>   #if @HAVE_UNSIGNED_LONG_LONG_INT@&&  ULONG_MAX>>  31 == 1
>   typedef unsigned long long int gl_uintmax_t;
> @@ -291,6 +298,7 @@ typedef unsigned long long int gl_uintmax_t;
>   typedef unsigned long int gl_uintmax_t;
>   # define uintmax_t gl_uintmax_t
>   #endif
> +#endif
>
>   /* Verify that intmax_t and uintmax_t have the same size.  Too much code
>      breaks if this is not the case.  If this check fails, the reason is likely
> @@ -431,8 +439,8 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
>
>   /* 7.18.2.5. Limits of greatest-width integer types */
>
> +#ifndef INTMAX_MAX
>   #undef INTMAX_MIN
> -#undef INTMAX_MAX
>   #ifdef INT64_MAX
>   # define INTMAX_MIN  INT64_MIN
>   # define INTMAX_MAX  INT64_MAX
> @@ -440,13 +448,15 @@ typedef int _verify_intmax_size[sizeof (intmax_t) == sizeof (uintmax_t)
>   # define INTMAX_MIN  INT32_MIN
>   # define INTMAX_MAX  INT32_MAX
>   #endif
> +#endif
>
> -#undef UINTMAX_MAX
> +#ifndef UINTMAX_MAX
>   #ifdef UINT64_MAX
>   # define UINTMAX_MAX  UINT64_MAX
>   #else
>   # define UINTMAX_MAX  UINT32_MAX
>   #endif
> +#endif
>
>   /* 7.18.3. Limits of other integer types */
>

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Jan Djärv]

Bruno Haible skrev 2011-07-09 12.27:
> Jan Djärv writes:
>
>>> Somewhere in gnulib, intmax_t gets defined to int64_t thus causing
>>> compiler warnings and general confusion (the code says intmax_t but is
>>> really int64_t).  AFAIK, all versions of OSX have intmax_t.
>
> Please provide a reproducible test case, preferrably outside Emacs.

Outside Emacs is hard, since I don't know what code uses gnulib or how to use 
it standalone.

>
> Also, I don't understand what's the problem: intmax_t must be 64-bit on
> MacOS X. No compiler supports 128-bit integers, AFAIK. Can you explain?
>

See reply to Paul.
Basically intmax_t is long and int64_t is long long.  Same size though.

For example:

intmax_t x;
...
printf ("%jd", x);

gives a compiler warning:

warning: format ‘%jd’ expects type ‘intmax_t’, but argument 2 has type ‘int64_t’

The naive fix is to cast x:

printf ("%jd", (intmax_t)x);

but that don't work because intmax_t is a define to int64_t.

	Jan D.

> Paul Eggert wrote:
>> Which compiler and OS version are you using?
>>
>> Does the following (untested) patch to lib/stdint.in.h fix your problem?
>>
>> diff --git a/lib/stdint.in.h b/lib/stdint.in.h
>> index c44401f..0dd60b9 100644
>> --- a/lib/stdint.in.h
>> +++ b/lib/stdint.in.h
>> @@ -270,6 +270,11 @@ typedef unsigned long int gl_uintptr_t;
>>   /* Note: These types are compiler dependent. It may be unwise to use them in
>>      public header files. */
>>
>> +/* If the system defines INTMAX_MAX, assume that intmax_t works, and
>> +   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
>> +   assuming one type where another is used by the system.  */
>> +
>> +#ifndef INTMAX_MAX
>>   #undef intmax_t
>>   #if @HAVE_LONG_LONG_INT@&&  LONG_MAX>>  30 == 1
>>   typedef long long int gl_intmax_t;
>> @@ -280,7 +285,9 @@ typedef long long int gl_intmax_t;
>>   typedef long int gl_intmax_t;
>>   # define intmax_t gl_intmax_t
>>   #endif
>> +#endif
>
> Untested patches are OK in simple areas. But in complex areas like stdint.in.h
> I would really like to understand the problem before applying any patch. That
> means, provide a reproducible sample (including all details about OS, compiler,
> compiler options), and show the preprocessing result (output of "$CC -E" or
> - even better - "$CC -E -dD") of the code that gives warnings.
>
> Bruno

bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion.

[Paul Eggert]

On 07/09/2011 03:27 AM, Bruno Haible wrote:
> Untested patches are OK in simple areas. But in complex areas like stdint.in.h
> I would really like to understand the problem before applying any patch.
I think Jan's other messages explain it pretty well
(plus, he tested it :-).

We had a similar problem with int64_t on Mac OS X
a few months back.  I installed the patch into gnulib
and propagated it into Emacs.  I did change one minor
thing: the installed patch respects the system's INTMAX_C
and UINTMAX_C macros, so that they're more likely to
be consistent too.