On 09/18/19 17:16, Kinney, Michael D wrote:
>> -----Original Message-----
>> From: Laszlo Ersek <ler...@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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#47492): https://edk2.groups.io/g/devel/message/47492
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]
-=-=-=-=-=-=-=-=-=-=-=-
