Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

["Leif Lindholm" <leif.lindholm@linaro.org>]

On Wed, Sep 18, 2019 at 08:55:42AM -0700, Andrew Fish via Groups.Io wrote:
> >> #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:
> 
> 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.

I think adding a strict mode to the specification should be doable -
an important aspect is that this should[1] only break *builds* of
existing code, never the execution of existing applications/drivers on
firmware built to the strict mode. (Unless I'm missing something
obvious.)

[1] It is always possible *some* toolchain does something weird that
    is already wrong but not visible, and this change would expose the
    underlying fault. This is not necessarily bad.

The specification could then describe the problematic types within
#ifdef starements.

Best Regards,

Leif

> 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?
>
> Thanks,
> 
> Andrew Fish
> 
> >  EFI_HANDLE Foobar;
> >  UINT64     Val;
> > 
> >  Foobar = &Val;
> > 
> > Thanks
> > Laszlo
> > 
> > 
> 
> 
> 
>