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

["Laszlo Ersek" <lersek@redhat.com>]

On 09/18/19 17:16, Kinney, Michael D wrote:
>> -----Original Message-----
>> From: Laszlo Ersek <lersek@redhat.com>

>> 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 can't test "all" compilers :), but yes, per the C standard, it has to.
"Foobar" is a pointer-to-void, and "&Val" is a
pointer-to-unsigned-long-long. Such an assignment satisfies the
following passages in C99:

6. Language
  6.3 Conversions
    6.3.2 Other operands
      6.3.2.3 Pointers

        1 A pointer to void may be converted to or from a pointer to any
          incomplete or object type. A pointer to any incomplete or
          object type may be converted to a pointer to void and back
          again; the result shall compare equal to the original pointer.

  6.5 Expressions
    6.5.4 Cast operators

      Constraints

      3 Conversions that involve pointers, other than where permitted by
        the constraints of 6.5.16.1, shall be specified by means of an
        explicit cast.

    6.5.16 Assignment operators
      6.5.16.1 Simple assignment

        Constraints

        1 One of the following shall hold:

          [...]

          - one operand is a pointer to an object or incomplete type and
            the other is a pointer to a qualified or unqualified version
            of void, and the type pointed to by the left has all the
            qualifiers of the type pointed to by the right;

          [...]

> I thought we usually have to add some typecasts:
>
>    Foobar = (EFI_HANDLE)&Val;

That's exactly the problem with EFI_HANDLE being a typedef to (void*) --
the explicit cast is not required.

Note the "other than" language in 6.5.4 paragraph 3.

> 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.

The problem is that the

  Foobar = &Val;

assignment is technically valid, considering both the C standard and the
UEFI spec. Breaking it would be a semantic improvement, but still in
conflict with what UEFI-2.8 promises.

Thanks
Laszlo