From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#9025: 24.0.50; gnulib defines intmax_t to int64_t on OSX, causes warnings and confusion. Date: Sat, 09 Jul 2011 13:25:54 +0200 Message-ID: <4E183AC2.2010103__44902.0960405052$1310210848$gmane$org@swipnet.se> References: <4E1826ED.9020602@cs.ucla.edu> <201107091227.03099.bruno@clisp.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1310210848 13097 80.91.229.12 (9 Jul 2011 11:27:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 9 Jul 2011 11:27:28 +0000 (UTC) Cc: 9025@debbugs.gnu.org, Paul Eggert , bug-gnulib@gnu.org To: Bruno Haible Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jul 09 13:27:23 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QfVgw-0002ng-4U for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 13:27:22 +0200 Original-Received: from localhost ([::1]:43157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfVgv-0001TJ-A6 for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Jul 2011 07:27:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfVgd-0001Sw-O8 for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:27:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QfVgc-0002FR-Ro for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:27:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfVgc-0002FN-P8 for bug-gnu-emacs@gnu.org; Sat, 09 Jul 2011 07:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1QfVgc-0003xn-6w; Sat, 09 Jul 2011 07:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Jul 2011 11:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9025-submit@debbugs.gnu.org id=B9025.131021076315148 (code B ref 9025); Sat, 09 Jul 2011 11:27:02 +0000 Original-Received: (at 9025) by debbugs.gnu.org; 9 Jul 2011 11:26:03 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfVfe-0003wH-Ug for submit@debbugs.gnu.org; Sat, 09 Jul 2011 07:26:03 -0400 Original-Received: from smtprelay-h21.telenor.se ([195.54.99.196]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfVfd-0003vp-Fi for 9025@debbugs.gnu.org; Sat, 09 Jul 2011 07:26:02 -0400 Original-Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 9DF61E8339 for <9025@debbugs.gnu.org>; Sat, 9 Jul 2011 13:25:55 +0200 (CEST) X-SENDER-IP: [85.225.45.100] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvhiAKg6GE5V4S1kPGdsb2JhbABThESESJ5ECwEBAQEeGQ0liHoCsjGQDoErhACBDwSXUoMkiCc X-IronPort-AV: E=Sophos;i="4.65,503,1304287200"; d="scan'208";a="205091871" Original-Received: from c-642de155.25-1-64736c10.cust.bredbandsbolaget.se (HELO coolsville.localdomain) ([85.225.45.100]) by ipb2.telenor.se with ESMTP; 09 Jul 2011 13:25:55 +0200 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 61C8B7FA05A; Sat, 9 Jul 2011 13:25:54 +0200 (CEST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <201107091227.03099.bruno@clisp.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 09 Jul 2011 07:27:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:48325 Archived-At: Bruno Haible skrev 2011-07-09 12.27: > Jan Dj=C3=A4rv writes: > >>> Somewhere in gnulib, intmax_t gets defined to int64_t thus causing >>> compiler warnings and general confusion (the code says intmax_t but i= s >>> 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=20 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 =E2=80=98%jd=E2=80=99 expects type =E2=80=98intmax_t=E2=80= =99, but argument 2 has type =E2=80=98int64_t=E2=80=99 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 proble= m? >> >> 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 wit= h >> + assuming one type where another is used by the system. */ >> + >> +#ifndef INTMAX_MAX >> #undef intmax_t >> #if @HAVE_LONG_LONG_INT@&& LONG_MAX>> 30 =3D=3D 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 stdi= nt.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, c= ompiler, > compiler options), and show the preprocessing result (output of "$CC -E= " or > - even better - "$CC -E -dD") of the code that gives warnings. > > Bruno