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 034131A1DF8 for ; Mon, 26 Sep 2016 08:31:39 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 62DB220278; Mon, 26 Sep 2016 15:31:38 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-12.phx2.redhat.com [10.3.116.12]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QFVaYL018322; Mon, 26 Sep 2016 11:31:37 -0400 To: "Cohen, Eugene" References: From: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , "Kinney, Michael D" , Alexei Fedorov Message-ID: <0de4dd03-faa7-1608-9625-369ab5d6e682@redhat.com> Date: Mon, 26 Sep 2016 17:31:36 +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.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 26 Sep 2016 15:31:38 +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: Mon, 26 Sep 2016 15:31:39 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/26/16 15:46, Cohen, Eugene wrote: > Get ready for a potentially stupid question (or at least a question I > probably should know the answer to by now)... This is a perfectly valid question. I print INTN / UINTN values with: - casting them unconditionally to INT64 / UINT64, - printing the converted values with the matching conversion specifiers, such as %Ld (for INT64) and %Lu or %Lx (for UINT64). This solution requires a bit more typing, and it is a bit pessimistic for 32-bit builds. On the positive side, it is robust / portable, and completely valid C. It is inspired by the standard C types intmax_t / uintmax_t. If you write portable C code and want to print a value of some integer type, where the spec only states "signed" or "unsigned integer type", but the actual type is either implementation defined or unspecified, converting the value to intmax_t / uintmax_t, and then printing it with %jd vs. %ju / %jx, is safe. Regarding %p (relayed by Alexei as a recommendation from years ago), that's a bug. %p takes a pointer to void. If we ever enable format string checking in edk2, for example with GCC's __attribute__((format(printf, ..., ...))), all those calls will blow up. Thanks Laszlo