On 09/18/19 17:55, Andrew Fish wrote: > > >> On Sep 18, 2019, at 1:41 AM, Laszlo Ersek <ler...@redhat.com> wrote: >> >> 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: >> > > 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 break 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 tables that > may be problematic. > > 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 standard > kind of thing?
Hmmm, okay. That makes sense. The macro could be advertised as, "this will give your project / platform some extra safety, but it will place coding style requirements on your project / platform that go beyond, and sometimes conflict (in case of semantically bogus code), with the UEFI spec". Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#47494): https://edk2.groups.io/g/devel/message/47494 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] -=-=-=-=-=-=-=-=-=-=-=-
