From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2760 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: printf warning with uintmax_t Date: Sat, 9 Feb 2013 13:03:19 +0100 Message-ID: <20130209120318.GY6181@port70.net> References: <1360361439.23424.95.camel@eris.loria.fr> <20130208221408.GN20323@brightrain.aerifal.cx> <1360398900.23424.151.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1360411420 8018 80.91.229.3 (9 Feb 2013 12:03:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Feb 2013 12:03:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2761-gllmg-musl=m.gmane.org@lists.openwall.com Sat Feb 09 13:04:02 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1U49A2-00066a-5j for gllmg-musl@plane.gmane.org; Sat, 09 Feb 2013 13:04:02 +0100 Original-Received: (qmail 17505 invoked by uid 550); 9 Feb 2013 12:03:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17438 invoked from network); 9 Feb 2013 12:03:31 -0000 Content-Disposition: inline In-Reply-To: <1360398900.23424.151.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2760 Archived-At: * Jens Gustedt [2013-02-09 09:35:00 +0100]: > Am Freitag, den 08.02.2013, 17:14 -0500 schrieb Rich Felker: > > It looks like we're not matching the ABI convention gcc expects, where > > [u]intmax_t is the lowest-rank type capable of storing the full > > integer range (i.e. long on 64-bit systems). > > I didn't check how you do this in musl, but for me gcc without any > includes has > > #define __INTMAX_TYPE__ long int > > so I guess that macro is just what should be taken to match its > expectations for printf formats. You still could have a fallback for > compilers that don't provide this. I checked for clang and it does, > BTW. tcc, pcc, cparse (the firm frontend) does not define __INTMAX_TYPE__ and clang blindly follows gcc there may be various possible definitions for intmax_t, assuming a given abi, and the compiler has no business knowing which one is choosen by the libc of course printf format checking, c++ and c11 generics with builtin intmax_t functions change that i think it's better if the intmax_t definition is fixed for a given abi (so libc can define it without consulting the compiler), but just like with __WCHAR_TYPE__ it may be ifdefed: if __INTMAX_TYPE__ is defined then use that otherwise a default (however that adds an extra branch in the preprocessor for no good reason: it may change from compiler to compiler but it should not, the compilers should agree on something here) once this is sorted out inttypes.h should be fixed as well