On Fri, Apr 5, 2024 at 7:43 AM levi.yun <yeoreum....@arm.com> wrote:
>
> Hi Michael! Thanks for answer.
>
> > Converting these to a flexible array member would not be
> a backwards compatible change.
>
> That's the point. But at least when I see the compiler used in tool_def.txt,
> there's no compiler which doesn't support to flexible array member.
>
> Do we still need to consider the case building edk2 with lower version of
> comipler
> which isn't manifested in tool_def.txt?
That's not in question. What Mike is referring to here is, e.g:
typedef struct {
BOOLEAN Supported;
UINT64 KeyCount;
UINT64 CapabilityCount;
EFI_BLOCK_IO_CRYPTO_CAPABILITY Capabilities [1];
} EFI_BLOCK_IO_CRYPTO_CAPABILITIES1;
typedef struct {
BOOLEAN Supported;
UINT64 KeyCount;
UINT64 CapabilityCount;
EFI_BLOCK_IO_CRYPTO_CAPABILITY Capabilities [];
} EFI_BLOCK_IO_CRYPTO_CAPABILITIES2;
sizeof(EFI_BLOCK_IO_CRYPTO_CAPABILITIES1) !=
sizeof(EFI_BLOCK_IO_CRYPTO_CAPABILITIES2), so it's an ABI break.
And unfortunately many of these structs need to be ABI-stable (I took
this one off the spec, you can find many such cases by ctrl+F'ing
[1]).
Basically, it comes down to the ABI. If it breaks the ABI, you need to
figure out *if* it matters (e.g is it part of a protocol, or is it an
internal lib struct that does not need to be stable, is it ABI to some
external component).
Also, worth noting that the "[1]" pattern is UB, and only works
because GCC (et al) don't want to break a bunch of code. If you're
defining a new struct, there's no reason to use [1] as a flexible
array.
--
Pedro
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117454): https://edk2.groups.io/g/devel/message/117454
Mute This Topic: https://groups.io/mt/105305209/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
