On 09/17/19 22:22, Andrew Fish wrote:
On Sep 17, 2019, at 1:06 PM, Ni, Ray <firstname.lastname@example.org> wrote:Ray,
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?
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.
typedef VOID *EFI_PEI_FV_HANDLE;
typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
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:
Foobar = &Val;