On 5/14/20 8:59 PM, Vitaly Cheptsov via groups.io wrote:
Mike,
The code you posted may inflict undefined behaviour is not valid C for
several reasons. The compiler is free to do whatever it desires. Please
refer to ISO/IEC 9899 for more details.
If applications cast raw pointers to typed pointers without checking
their alignment, well, god bless them :)
My opinion is both the compiler and the hardware are welcome to do the
worst once your third line is discovered. On a number of CPUs such
addresses cannot be even represented in the first place.
Yet, once again it is out of the scope of the current problem.
This has come up a couple of times in the past, and it is indeed a
serious issue with the EDK2 codebase.
For example, in BaseLib we have
UINT16
EFIAPI
WriteUnaligned16 (
OUT UINT16 *Buffer,
IN UINT16 Value
);
which does not make any sense, since a UINT16* is defined as being
aligned to 16 bits, and so the compiler is permitted to generate code
assuming that constraint is never violated.
So the correct way would be to define this prototype as
UINT16
EFIAPI
WriteUnaligned16 (
OUT VOID *Buffer,
IN UINT16 Value
);
and let the underlying implementation deal with the misalignment.
As I said, I'm sure this has come up in the past, and there may even be
a bugzilla entry for it.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#59588): https://edk2.groups.io/g/devel/message/59588
Mute This Topic: https://groups.io/mt/74201257/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
