From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 979CC1A1DF1 for ; Tue, 27 Sep 2016 11:31:37 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0684FC04D2B1; Tue, 27 Sep 2016 18:31:37 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-5.phx2.redhat.com [10.3.116.5]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8RIVYqs017338; Tue, 27 Sep 2016 14:31:35 -0400 To: "Brian J. Johnson" , Andrew Fish , Eugene Cohen References: <0de4dd03-faa7-1608-9625-369ab5d6e682@redhat.com> <334067f6-b7b6-9fe4-02c6-f8af21982780@sgi.com> Cc: Mike Kinney , Alexei Fedorov , "edk2-devel@lists.01.org" From: Laszlo Ersek Message-ID: <77c5fdc5-00fb-2f65-5143-1fba3fd62091@redhat.com> Date: Tue, 27 Sep 2016 20:31:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <334067f6-b7b6-9fe4-02c6-f8af21982780@sgi.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 27 Sep 2016 18:31:37 +0000 (UTC) Subject: Re: What is the right way to print a UINTN? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2016 18:31:37 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/27/16 19:14, Brian J. Johnson wrote: > On 09/27/2016 11:47 AM, Andrew Fish wrote: >> >>> On Sep 27, 2016, at 9:03 AM, Cohen, Eugene wrote: >>> >>>> Printing UINTN with %x *or* with %d are equally bugs. >>>> >>>> For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to >>>> work most of the time). >>> >>> Feel free to file a Bugzilla on the extensive usage of this in >>> edk2 [ducking and running]. :) >>> >>>>> I'm envisioning having to create a slide in the future for UEFI >>>>> training about the proper use of UINTNs and describing "If you think >>>>> it may exceed 2^32-1 then upcast to UINT64, otherwise don't worry >>>>> about it" and it makes me squirm. >>>> >>>> It makes me squirm too. I think the slide should recommend the >>>> casting >>>> that I proposed. ;) "There is no conversion specifier dedicated to >>>> UINTN; the portable way to print it is to cast it to UINT64, then print >>>> it with %Lx." >>> >>> This is reasonable although I expect to get asked why a lot of the >>> other code doesn't adhere to this recommendation. >>> >> >> I think this is a historical artifact. The older version of %x in >> the EDK (and early edk2) implied UINTN. We hit an issue with C >> integer math resulting in an int and that seemed to bork some >> toolchains. That is when things changed from UINTN to int. I guess >> the cleanup was practical vs. pedantic. > > Thanks for the historical context, Andrew. It's interesting to hear, > if very unfortunate. > > I've written code in the past which uses a #defined value for the > UINTN format character as a way to work around this issue without > casting everything to 64 bits. Something like: > > // Format string for a naturally-sized unsigned integer > #if defined (MDE_CPU_IA32) > #define UINTN_FMT "0x%08x" > #elif defined (MDE_CPU_X64) > #define UINTN_FMT "0x%016lx" > #elif ... > ... > #endif > > UINTN Val; > Val = Foo (); > DEBUG((DEBUG_INFO, "Value is " UINTN_FMT "\n", Val)); > > > I guess it's a matter of opinion if that's preferable to adding casts; > in my particular situation, I had to print values with that particular > format string in a lot of places, so it was convenient to #define it > once. I find this great; standard C also has macros for format specifiers, for example PRIu64, PRId32, PRIx64, and so on. PrintLib.h could be extended with PRIuN ("u"/"Lu"), PRIxN ("x"/"Lx"), PRIdN ("d"/"Ld") and PRIiN ("i"/"Li"), to be defined similarly to your code above (covering all supported CPU architectures). Then code could use them like DEBUG ((DEBUG_INFO, "Value is 0x%" PRIxN "\n", Val)); The field width, if necessary, can be passed in as an argument, DEBUG ((DEBUG_INFO, "Value is 0x%0*" PRIxN "\n", 2 * sizeof Val, Val)); If this is deemed too messy, we could define further macros for the zero-padded conversions. Thanks, Laszlo