From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3BD351A1DF1 for ; Tue, 27 Sep 2016 11:20:30 -0700 (PDT) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga103.fm.intel.com with ESMTP; 27 Sep 2016 11:20:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,406,1470726000"; d="scan'208";a="13837348" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga005.fm.intel.com with ESMTP; 27 Sep 2016 11:20:29 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.161]) by ORSMSX104.amr.corp.intel.com ([169.254.4.228]) with mapi id 14.03.0248.002; Tue, 27 Sep 2016 11:20:29 -0700 From: "Kinney, Michael D" To: "afish@apple.com" , "Kinney, Michael D" CC: Eugene Cohen , Alexei Fedorov , "edk2-devel@lists.01.org" , Laszlo Ersek Thread-Topic: [edk2] What is the right way to print a UINTN? Thread-Index: AdIX/FZUkJ+/GDfSRZe7u7ShyrQtxgASWdEAACvtKYAABDdLAAADQGEAAAGJsAAADkOVQP//npMAgABvU4A= Date: Tue, 27 Sep 2016 18:20:28 +0000 Message-ID: References: <0de4dd03-faa7-1608-9625-369ab5d6e682@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjBmMzg1MmEtY2M5My00MzVhLTkzOGUtZmE2M2NkNzhlYmY3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImJSc3hZd25MRjVjXC9TR2s3RCtFQW9BR0pcL0xsZkJtbmpaRFwvVmtEMHdVSlk9In0= x-originating-ip: [10.22.254.138] MIME-Version: 1.0 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:20:30 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, Yes. Using fixed with base types instead of natural width base types is cl= earer and very portable. We do use UINTN in UEFI/PI spec APIs on purpose when the range of the argum= ent=20 does need vary for different CPU widths. Using UINTN in function args=20 and local variables also generates smaller code in most cases because UINTN usually matches the stack and register width. So there are good reasons to= =20 use UINTN/INTN. I did find the commit where the use of 'int' was added to pull arguments fr= om the=20 var arg list. Dated 6/3/2006. SHA-1: 1d580c14473896b5b593a7f60a21f532008265d0 * 1) Add support for %p to print pointers 2) Fix %d,%x,%X to pull values off the vararg stack using (int) and (unsi= gned int)=20 types to resolve compatibility issues with X64 Best regards, Mike > -----Original Message----- > From: afish@apple.com [mailto:afish@apple.com] > Sent: Tuesday, September 27, 2016 10:47 AM > To: Kinney, Michael D > Cc: Eugene Cohen ; Alexei Fedorov = ; edk2- > devel@lists.01.org ; Laszlo Ersek > Subject: Re: [edk2] What is the right way to print a UINTN? >=20 >=20 > > On Sep 27, 2016, at 10:27 AM, Kinney, Michael D wrote: > > > > Andrew, > > > > Here is the comment in current code that explains some of the why. > > > > case 'd': > > if ((Flags & LONG_TYPE) =3D=3D 0) { > > // > > // 'd', 'u', 'x', and 'X' that are not preceded by 'l' or 'L' = are assumed to > be type "int". > > // This assumption is made so the format string definition is = compatible > with the ANSI C > > // Specification for formatted strings. It is recommended tha= t the Base > Types be used > > // everywhere, but in this one case, compliance with ANSI C is= more > important, and > > // provides an implementation that is compatible with that lar= gest possible > set of CPU > > // architectures. This is why the type "int" is used in this = one case. > > // > > > > If code uses type UINTN or INTN, then the max value that can be used > > for portable sources is max value for the CPU arch with the smallest > > UINTN width. For the CPU archs in UEFI/PI specs today, the smallest UI= NTN > > width is 32-bits. > > > > Portable sources that use type UINTN must never use values larger than > > 32-bits. Same for type INTN. Only use values in signed 32-bit range. > > > > It is possible for 64-bit specific sources to use type UINTN with value= s > > larger than 32-bits, but those sources would not be portable and would > > need to be changed to UINT64 to be portable. Is this the case that are > > really discussing here? > > >=20 > If you have a UINTN that can only represent 32-bits is that not a UINT32 = :). >=20 > Thanks, >=20 > Andrew Fish >=20 > > Thanks, > > > > Mike > > > > > >> -----Original Message----- > >> From: afish@apple.com [mailto:afish@apple.com] > >> Sent: Tuesday, September 27, 2016 9:47 AM > >> To: Eugene Cohen > >> Cc: Laszlo Ersek ; Kinney, Michael D > ; > >> Alexei Fedorov ; edk2-devel@lists.01.org >> devel@ml01.01.org> > >> Subject: Re: [edk2] What is the right way to print a UINTN? > >> > >> > >>> 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 t= o > >>>> 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 thin= k > >>>>> 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 pr= int > >>>> it with %Lx." > >>> > >>> This is reasonable although I expect to get asked why a lot of the ot= her 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, > >> > >> 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