Well, I explicitly added this macro as a prerequisite to code used in our new PE library (remember this patch was initially sent in 2021). We still require it downstream, but obviously upstream is not interested in the related contributions that were to follow at the time.
Gerd picked it up because he wanted to attempt to re-try contributing the new PE library, but I haven't heard from him in weeks. Design-wise, I agree it could be removed again. However, there first was a downstream burden when adding it (as we needed to rewrite our history to drop our downstream patch in favour of the upstream solution). Now introducing another downstream burden *again* to remove the macro that was added only a few weeks back would be a sign of poor management and planning. Best regards, Marvin > On 15. May 2023, at 17:15, Rebecca Cran <[email protected]> wrote: > > On 5/15/23 08:45, Pedro Falcato wrote: >> -#define ALIGN_VALUE_ADDEND(Value, Alignment) (((Alignment) - (Value)) & >> ((Alignment) - 1U)) >> +#define ALIGN_VALUE_ADDEND(Value, Alignment) ((~(Value)) & ((Alignment) - >> 1U)) >> /** >> Rounds a value up to the next boundary using a specified alignment. >> @@ -945,7 +945,7 @@ STATIC_ASSERT (ALIGNOF (__VERIFY_INT32_ENUM_SIZE) == >> sizeof (__VERIFY_INT32_ENUM >> @return A value up to the next boundary. >> **/ >> -#define ALIGN_VALUE(Value, Alignment) ((Value) + ALIGN_VALUE_ADDEND >> (Value, Alignment)) >> +#define ALIGN_VALUE(Value, Alignment) (((Value) + (Alignment - 1)) & >> ~(Alignment)) > > Since ALIGN_VALUE_ADDEND is only used in ALIGN_VALUE, it should probably be > deleted instead of updated. > > > -- > > Rebecca Cran > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#104886): https://edk2.groups.io/g/devel/message/104886 Mute This Topic: https://groups.io/mt/98904940/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
