From owner-svn-src-projects@FreeBSD.ORG Fri Aug 15 01:34:56 2014 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E521B615; Fri, 15 Aug 2014 01:34:55 +0000 (UTC) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 749892CCB; Fri, 15 Aug 2014 01:34:55 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 9F4A9D48960; Fri, 15 Aug 2014 11:34:47 +1000 (EST) Date: Fri, 15 Aug 2014 11:34:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andrew Turner Subject: Re: svn commit: r269995 - projects/arm64/sys/arm64/include In-Reply-To: <201408141846.s7EIkU4v042685@svn.freebsd.org> Message-ID: <20140815105202.C1151@besplex.bde.org> References: <201408141846.s7EIkU4v042685@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=AOuw8Gd4 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=MjG9SfkE-rEA:10 a=jIW9Tjywsa0A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=T4yEQg16rXpWJAJiFJ4A:9 a=CjuIK1q_8ugA:10 Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 01:34:56 -0000 On Thu, 14 Aug 2014, Andrew Turner wrote: > Log: > Fix the PRI*64 and SCN*64 macros. We use long long for 64-bit typedefs. Why not fix the typedefs? They should use the minimal rank that works, although this gives the weirdness that intmax_t has lower rank than long long. All other 64-bit arches follow this rule. Following this rule minimises use of the long long abomination, and may expose broken code slightly less. > Modified: projects/arm64/sys/arm64/include/_inttypes.h > ============================================================================== > --- projects/arm64/sys/arm64/include/_inttypes.h Thu Aug 14 18:44:08 2014 (r269994) > +++ projects/arm64/sys/arm64/include/_inttypes.h Thu Aug 14 18:46:30 2014 (r269995) > @@ -42,32 +42,32 @@ > #define PRId8 "d" /* int8_t */ > #define PRId16 "d" /* int16_t */ > #define PRId32 "d" /* int32_t */ > -#define PRId64 "ld" /* int64_t */ > +#define PRId64 "lld" /* int64_t */ No one should notice this change, since the existence of PRI* is an even larger bug than the existence of long long. Broken code that might be exposed more by unnecessary use of long long include things like hard-coding virtual addresses as u_long and printing them with %lx. This hard-coding works on all arches supported by FreeBSD. However, FreeBSD is supposed to use vm_offset_t for virtual addresses, so just printing them correcety requires casting to uintmax_t. (One reason the PRI* mistake is negatively useful is that converting from vm_offset_t to a minimal type that works with PRI* is even harder that converting it to a minimal basic types). Most MD code doesn't bother with this, and just hard-codes a format that works with the given arch. E.g., in pmap. vm_offset is normally defined as a uintN_t, so the rule about using the minimal rank that works applies to it too. E.g., on i386, uint32_t is declared as u_int, not u_long. This minimises unnecessary use of u_long. Old code in i386 pmap depends on this -- it hard-codes the format as %x. 64-bit pmap normally hard-codes it as %lx instead. arm64 would have to use %llx instead. Printf formats are relatively unimportant, especially in the kernel, and wrong ones are not required to be detected, and the detection is even more broken than it used to be since some compilers don't support kernel format extensions and the "fix" for that is to turn off all format checking. You could get similar type errors that must be detected by mixing APIs or hacking with u_long when you should really use vm_offset_t. One API might use vm_offset_t == uintN_t == [ u_long on all arches except arm64; u_long_long on arm64 ] and another API might use u_long. Then passing pointers between these APIs causes type mismatches that must be detected if a prototype is in scope, although everything is either 32 bits or 64 bits so there is no ABI mismatch. Bruce