From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.sgi.com [192.48.180.66]) by ml01.01.org (Postfix) with ESMTP id 7B6051A1DF5 for ; Tue, 27 Sep 2016 10:14:29 -0700 (PDT) Received: from xmail.sgi.com (pv-excas3-dc21.corp.sgi.com [137.38.106.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8F1C58F8033; Tue, 27 Sep 2016 10:14:28 -0700 (PDT) Received: from [128.162.232.243] (128.162.232.243) by xmail.sgi.com (137.38.106.6) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Sep 2016 12:14:28 -0500 To: Andrew Fish , Eugene Cohen References: <0de4dd03-faa7-1608-9625-369ab5d6e682@redhat.com> From: "Brian J. Johnson" CC: Mike Kinney , Alexei Fedorov , "edk2-devel@lists.01.org" , Laszlo Ersek Message-ID: <334067f6-b7b6-9fe4-02c6-f8af21982780@sgi.com> Date: Tue, 27 Sep 2016 12:14:27 -0500 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: X-Originating-IP: [128.162.232.243] 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 17:14:29 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit 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. > > Thanks, > > Andrew Fish > >> Thanks, >> >> Eugene >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > -- Brian J. Johnson -------------------------------------------------------------------- My statements are my own, are not authorized by SGI, and do not necessarily represent SGI’s positions.