From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 18 Sep 2019 10:41:32 -0700 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5151A3D3A0; Wed, 18 Sep 2019 17:41:31 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-125-22.rdu2.redhat.com [10.10.125.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 294835D6A5; Wed, 18 Sep 2019 17:41:25 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID To: "Kinney, Michael D" , Andrew Fish , "Ni, Ray" Cc: "devel@edk2.groups.io" , Achin Gupta , Anthony Perard , Ard Biesheuvel , "You, Benjamin" , "Zhang, Chao B" , "Bi, Dandan" , David Woodhouse , "Dong, Eric" , "Dong, Guo" , "Wu, Hao A" , "Carsey, Jaben" , "Wang, Jian J" , "Wu, Jiaxin" , "Yao, Jiewen" , "Justen, Jordan L" , Julien Grall , Leif Lindholm , "Gao, Liming" , "Ma, Maurice" , "Fu, Siyuan" , Supreeth Venkatesh , "Gao, Zhichao" References: <20190917194935.24322-1-lersek@redhat.com> <20190917194935.24322-2-lersek@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C2E3BE1@SHSMSX104.ccr.corp.intel.com> <1FFFA19B-454C-4B46-9DD0-339BB8011838@apple.com> From: "Laszlo Ersek" Message-ID: <8845b133-63db-466c-73d7-f373b06d7f09@redhat.com> Date: Wed, 18 Sep 2019 19:41:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.68]); Wed, 18 Sep 2019 17:41:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 09/18/19 17:16, Kinney, Michael D wrote: >> -----Original Message----- >> From: Laszlo Ersek >> However, if we wanted to allow new projects to #define >> STRICTER_UEFI_TYPES as their normal mode of operation >> (and not just for a sanity check in CI), then we'd have >> to update the UEFI spec too. >> >> Otherwise, code that is technically spec-conformant >> (albeit semantically nonsensical), like I mentioned up- >> thread, would no longer compile: >> >> EFI_HANDLE Foobar; >> UINT64 Val; >> >> Foobar = &Val; > > Does this example build without warnings on all compilers. I can't test "all" compilers :), but yes, per the C standard, it has to. "Foobar" is a pointer-to-void, and "&Val" is a pointer-to-unsigned-long-long. Such an assignment satisfies the following passages in C99: 6. Language 6.3 Conversions 6.3.2 Other operands 6.3.2.3 Pointers 1 A pointer to void may be converted to or from a pointer to any incomplete or object type. A pointer to any incomplete or object type may be converted to a pointer to void and back again; the result shall compare equal to the original pointer. 6.5 Expressions 6.5.4 Cast operators Constraints 3 Conversions that involve pointers, other than where permitted by the constraints of 6.5.16.1, shall be specified by means of an explicit cast. 6.5.16 Assignment operators 6.5.16.1 Simple assignment Constraints 1 One of the following shall hold: [...] - one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; [...] > I thought we usually have to add some typecasts: > > Foobar = (EFI_HANDLE)&Val; That's exactly the problem with EFI_HANDLE being a typedef to (void*) -- the explicit cast is not required. Note the "other than" language in 6.5.4 paragraph 3. > Or > > Foobar = (EFI_HANDLE)(UINTN)&Val; > > For examples like this, adding an explicit typecast would be an > improvement. So finding and reviewing and fixing these would be > a good improvement. The problem is that the Foobar = &Val; assignment is technically valid, considering both the C standard and the UEFI spec. Breaking it would be a semantic improvement, but still in conflict with what UEFI-2.8 promises. Thanks Laszlo