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 024CE1A1DF5 for ; Tue, 27 Sep 2016 09:31:23 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 3BAAA7F36F; Tue, 27 Sep 2016 16:31:23 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-5.phx2.redhat.com [10.3.116.5]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8RGVLV5022981; Tue, 27 Sep 2016 12:31:22 -0400 To: "Cohen, Eugene" References: <0de4dd03-faa7-1608-9625-369ab5d6e682@redhat.com> Cc: "Kinney, Michael D" , Alexei Fedorov , "edk2-devel@lists.01.org" From: Laszlo Ersek Message-ID: <4fd335cf-31c6-5943-ead7-ccbd4c8d0787@redhat.com> Date: Tue, 27 Sep 2016 18:31:21 +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: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 27 Sep 2016 16:31:23 +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 16:31:24 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/27/16 18:03, 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]. :) Not a bad idea, but it's not practical. I take care to use the right casts and conversion specifiers whenever I write new code, but for identifying existent incorrect calls, compiler support would be necessary. I guess we could add the GCC function attribute that I mentioned earlier to some of the PrintLib functions, and then address the resultant warning messages. The problem is that some of the edk2-defined conversion specifiers - are not defined in standard (or GNU) C -- for example, %t --, which might prevent GCC from pairing the corresponding argument with any conversion specifier at all, - and/or work differently from their standard (or GNU) C counterparts: - for example %g is entirely different between edk2 and standard C ((EFI_GUID *) vs. double), - the "L" length modifier is invalid for %x in standard C, - etc. If someone is into GCC or CLANG plugin development, creating an "edk2 PrintLib" function attribute could be a good task :) >>> 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. "Because people didn't realize it was a bug and it worked in practice"? :) Thanks Laszlo