From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=WsEDz8fy; spf=pass (domain: apple.com, ip: 17.151.62.66, mailfrom: afish@apple.com) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) by groups.io with SMTP; Wed, 18 Sep 2019 08:55:54 -0700 Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x8IFqcLX016571; Wed, 18 Sep 2019 08:55:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=goFiJNEO2gJKEaZlVMZuWMMDDZs9vxSatjwPTTxdEz0=; b=WsEDz8fyGGu26R7G5c5TqXaM2vScyM2nmRjGCBRdjc2VlHbmUEKj4AD+F0aIRQWBoA9m yG+jVe7eN5nOqPXjsJBYCOGQ/MmLF4Fsm7Sf3bH3EP6/xQ/BpZMp38Apa+/D6mU7rdk1 w7C/4FwQI0aXufvrEjoSpX/lPgYuU5zgpGE45eZ1TQKMEwHxMn8JTxHiSbn7bSdINQkU O4LC09ON5JzsVzNTEC7JSaGTxqyylpm3GiIkCBSI0LibGztn4Dmy2ZXldkFwUVNQ5KxG 00+j7mBVsm1WMiyep7Wad4e7KlOF4uQdO8dj7cTlRqrxbpiIpxBsLJxtijvV8ydqV1oM OQ== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2v37um7sqw-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Sep 2019 08:55:48 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PY1002K4AWXSV70@ma1-mtap-s03.corp.apple.com>; Wed, 18 Sep 2019 08:55:46 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PY100600APFCN00@nwk-mmpp-sz09.apple.com>; Wed, 18 Sep 2019 08:55:46 -0700 (PDT) X-Va-A: X-Va-T-CD: 08777febe38bb384cc57fda39d0586b7 X-Va-E-CD: 13e00072960b2d695dbad921c407f688 X-Va-R-CD: f08005d6ce5b4baa6c3b27af73d4b2fc X-Va-CD: 0 X-Va-ID: 7d2791f6-2a14-4aca-a832-c82f23ac5ad7 X-V-A: X-V-T-CD: 08777febe38bb384cc57fda39d0586b7 X-V-E-CD: 13e00072960b2d695dbad921c407f688 X-V-R-CD: f08005d6ce5b4baa6c3b27af73d4b2fc X-V-CD: 0 X-V-ID: 0cc997dd-bff1-4fbb-9ea2-7f2bc95a2618 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-18_09:,, signatures=0 Received: from [17.235.30.203] (unknown [17.235.30.203]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PY1000CKAWUDX00@nwk-mmpp-sz09.apple.com>; Wed, 18 Sep 2019 08:55:45 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID Date: Wed, 18 Sep 2019 08:55:42 -0700 In-reply-to: Cc: "Ni, Ray" , 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" , Jordan Justen , Julien Grall , Leif Lindholm , "Gao, Liming" , "Ma, Maurice" , Mike Kinney , "Fu, Siyuan" , Supreeth Venkatesh , "Gao, Zhichao" To: devel@edk2.groups.io, lersek@redhat.com 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> X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-09-18_08:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_8A53AFD8-0454-4EF2-866B-3C5B43B78285" --Apple-Mail=_8A53AFD8-0454-4EF2-866B-3C5B43B78285 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 18, 2019, at 1:41 AM, Laszlo Ersek wrote: >=20 > On 09/17/19 22:22, Andrew Fish wrote: >>=20 >>=20 >>> On Sep 17, 2019, at 1:06 PM, Ni, Ray wrote: >>>=20 >>> Laszlo, >>> Thank you very much for this work. >>> They are quite helpful to detect potential issues. >>>=20 >>> But without this specific patch being checked in, future break will st= ill happen. >>> I don't want it to be checked in ASAP because I know that there are qu= ite a lot of close source code that may get build break due to this change. >>> Besides that, what prevent you make the decision to check in the chang= es? >>>=20 >>=20 >> Ray, >>=20 >> I was thinking the same thing. Could we make this an optional feature v= ia a #define? We could always default to the Spec Behavior, and new project= s could opt into the stricter version.=20 >>=20 >> #ifndef STRICTER_UEFI_TYPES >> typedef VOID *EFI_PEI_FV_HANDLE; >> #else >> struct EFI_PEI_FV_OBJECT; >> typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE; >> #endif >=20 > Technically, this would work well. >=20 > 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. >=20 > Otherwise, code that is technically spec-conformant (albeit semantically > nonsensical), like I mentioned up-thread, would no longer compile: >=20 Laszlo, I think helping people NOT write nonsensical code is good. It is very good= idea and I'd like to add it to the spec but as you point out it would brea= k a lot of existing code so I'm not sure it is possible. I guess we could t= ry to add a strict mode to the spec but given the types are defined in tabl= es that may be problematic.=20 We have coding standards that are more strict than what the C spec allows.= So I would see the STRICT_UEFI_TYPES as more of a enforce the coding stand= ard kind of thing?=20 Thanks, Andrew Fish > EFI_HANDLE Foobar; > UINT64 Val; >=20 > Foobar =3D &Val; >=20 > Thanks > Laszlo >=20 >=20 --Apple-Mail=_8A53AFD8-0454-4EF2-866B-3C5B43B78285 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Sep 18= , 2019, at 1:41 AM, Laszlo Ersek <lersek@redhat.com> wrote:

On 09/17/19 22:22, Andrew Fish wrote:


On Sep 17, 2019,= at 1:06 PM, Ni, Ray <ray= .ni@intel.com> wrote:

Laszlo,
Thank you very much for this work.
They are quite help= ful to detect potential issues.

But without th= is specific patch being checked in, future break will still happen.
I don't want it to be checked in ASAP because I know that there are = quite a lot of close source code that may get build break due to this chang= e.
Besides that, what prevent you make the decision to check = in the changes?


Ra= y,

I was thinking the same thing. Could we mak= e this an optional feature via a #define? We could always default to the Sp= ec Behavior, and new projects could opt into the stricter version. 

#if= ndef STRICTER_UEFI_TYPES
typedef VOID    *EFI_= PEI_FV_HANDLE;
#else
struct EFI_PEI_FV_OBJECT;<= br class=3D"">typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
#endif

Technically, this would work well.

However, i= f we wanted to allow new projects to #define
STRICTER_UEFI_TYPES as their normal mode of operation= (and not just for
a s= anity check in CI), then we'd have to update the UEFI spec too.

Otherwise, code that is technically spec-conformant (albeit semantic= ally
nonsensical), like= I mentioned up-thread, would no longer compile:


Laszlo,

I think helping people NOT write nonsensical code is good. It is very goo= d idea and I'd like to add it to the spec but as you point out it would bre= ak a lot of existing code so I'm not sure it is possible. I guess we could = try to add a strict mode to the spec but given the types are defined in tab= les that may be problematic. 

We h= ave coding standards that are more strict than what the C spec allows. So I= would see the STRICT_UEFI_TYPES as more of a enforce the coding standard k= ind of thing? 

Thanks,
<= br class=3D"">
Andrew Fish

 EFI_HANDLE Foobar;
 UINT64   &nb= sp; Val;

 Foobar =3D &Val;

Th= anks
Laszlo


--Apple-Mail=_8A53AFD8-0454-4EF2-866B-3C5B43B78285--