> -----Original Message-----
> From: Laszlo Ersek <[email protected]>
> Sent: Wednesday, September 18, 2019 1:42 AM
> To: Andrew Fish <[email protected]>; Ni, Ray
> <[email protected]>
> Cc: [email protected]; Achin Gupta
> <[email protected]>; Anthony Perard
> <[email protected]>; Ard Biesheuvel
> <[email protected]>; You, Benjamin
> <[email protected]>; Zhang, Chao B
> <[email protected]>; Bi, Dandan
> <[email protected]>; David Woodhouse
> <[email protected]>; Dong, Eric
> <[email protected]>; Dong, Guo <[email protected]>;
> Wu, Hao A <[email protected]>; Carsey, Jaben
> <[email protected]>; Wang, Jian J
> <[email protected]>; Wu, Jiaxin
> <[email protected]>; Yao, Jiewen
> <[email protected]>; Justen, Jordan L
> <[email protected]>; Julien Grall
> <[email protected]>; Leif Lindholm
> <[email protected]>; Gao, Liming
> <[email protected]>; Ma, Maurice
> <[email protected]>; Kinney, Michael D
> <[email protected]>; Fu, Siyuan
> <[email protected]>; Supreeth Venkatesh
> <[email protected]>; Gao, Zhichao
> <[email protected]>
> Subject: Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY:
> edk2: turn standard handle types into pointers to non-
> VOID
> 
> On 09/17/19 22:22, Andrew Fish wrote:
> >
> >
> >> On Sep 17, 2019, at 1:06 PM, Ni, Ray
> <[email protected]> wrote:
> >>
> >> Laszlo,
> >> Thank you very much for this work.
> >> They are quite helpful to detect potential issues.
> >>
> >> But without this 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 change.
> >> Besides that, what prevent you make the decision to
> check in the changes?
> >>
> >
> > Ray,
> >
> > I was thinking the same thing. Could we make this an
> optional feature via a #define? We could always default
> to the Spec Behavior, and new projects could opt into
> the stricter version.
> >
> > #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
> 
> Technically, this would work well.
> 
> 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 thought we usually have to add some typecasts:

   Foobar = (EFI_HANDLE)&Val;

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.

> 
> Thanks
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#47482): https://edk2.groups.io/g/devel/message/47482
Mute This Topic: https://groups.io/mt/34180199/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to