On 09/17/19 22:22, Andrew Fish wrote: > > >> On Sep 17, 2019, at 1:06 PM, Ni, Ray <ray...@intel.com> 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; Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47469): https://edk2.groups.io/g/devel/message/47469 Mute This Topic: https://groups.io/mt/34180199/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
