On Thu, Mar 12, 2020 at 20:42:52 +0100, Laszlo Ersek wrote:
> On 03/12/20 15:44, Leif Lindholm wrote:
> > And what would you propose we do the next time the RISC-V toolchain
> > generates a memcpy call based on some other completely valid change to
> > core code?
>
> We could choose to enable the intrinsics library for RISC-V at that point.
We could. And have no time left for resolving any issues that may be
triggered by that without slipping the next stable tag. I would prefer
de-risking it.
> IIUC, the CreateDeviceManagerForm() code in question did break an edk2
> rule ("don't use structure assignment") *prior* to commit 64a228f5f893.
> The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it.
> This doesn't seem uncharted territory.
I don't understand, I've already said I'm not pushing to revert that
patch, I have suggested that we don't put RISC-V on less stable ground
than ARM/AARCH64.
But continuing on the unrelated topic:
If the rule is "no structure assignments", then fine, that's part of
the C dialect you need to learn in order to contribute to TianoCore.
I can separately start arguing for changing that rule.
However, I can't easily find that in the coding style - could you give
me a pointer?
/
Leif
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#55833): https://edk2.groups.io/g/devel/message/55833
Mute This Topic: https://groups.io/mt/71671270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
