Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 2019-08-16 18:09, rebe...@bsdio.com wrote: > Yes, that's going to be important. Given > https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015?view=vs-2019, > I suspect support for VS2008 might already have been broken, since it > reports that "static_assert" was introduced in Visual Studio 2010 - and > we use it in BaseTools/Source/C/Common/PcdValueCommon.h (the > _STATIC_ASSERT was added in September 2018): I just checked, and VS2008 SP1 _can_ build OVMF, though it looks like support has been removed for building _BaseTools_ with anything older than VS2012. From "edksetup.bat -h" ... ForceRebuild Force a full rebuild of BaseTools binaries. VS2012 Set the env for VS2012 build. VS2013 Set the env for VS2013 build. VS2015 Set the env for VS2015 build. VS2017 Set the env for VS2017 build. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#46180): https://edk2.groups.io/g/devel/message/46180 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 2019-08-16 18:03, Andrew Fish wrote: > It is also interesting in the context of our CI as we could pick oldest and > newest version from every compiler family for the CI build test. Yes, that's going to be important. Given https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015?view=vs-2019, I suspect support for VS2008 might already have been broken, since it reports that "static_assert" was introduced in Visual Studio 2010 - and we use it in BaseTools/Source/C/Common/PcdValueCommon.h (the _STATIC_ASSERT was added in September 2018): #if defined(_MSC_EXTENSIONS) #define __STATIC_ASSERT static_assert #else #define __STATIC_ASSERT _Static_assert #endif -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45876): https://edk2.groups.io/g/devel/message/45876 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
> On Aug 16, 2019, at 5:01 PM, Rebecca Cran wrote: > > On 2019-08-16 16:58, Andrew Fish via Groups.Io wrote: >> >> I'm all for modernization of the C code as long we are thoughtful >> about compatibility. For example I still see that VS2008 is a >> supported BaseTools/Conf/tools_def.template. > > > It would be interesting to see who's using the older toolchains against > current/newer revisions of the edk2. > > For example at work we build a UEFI driver using VS2012, but it's > against the UDK2014.SP1 branch, and being for a legacy product we'll > never migrate to a newer UDK release or master tag. > Rebecca, It is also interesting in the context of our CI as we could pick oldest and newest version from every compiler family for the CI build test. Thanks, Andrew Fish > > -- > Rebecca Cran > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45875): https://edk2.groups.io/g/devel/message/45875 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 2019-08-16 16:58, Andrew Fish via Groups.Io wrote: > > I'm all for modernization of the C code as long we are thoughtful > about compatibility. For example I still see that VS2008 is a > supported BaseTools/Conf/tools_def.template. It would be interesting to see who's using the older toolchains against current/newer revisions of the edk2. For example at work we build a UEFI driver using VS2012, but it's against the UDK2014.SP1 branch, and being for a legacy product we'll never migrate to a newer UDK release or master tag. -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45874): https://edk2.groups.io/g/devel/message/45874 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
are possible for compilers >>> that do not support this feature directly. This is why >>> the complete description of the EDK II version is required. >>> >>> I would like to see a V3 with the complete description. >>> >>> In general, I agree it is better if there is code that >>> uses a new feature in the code base, so the feature can >>> be tested. A second option we can consider going forward >>> is for unit test code to be submitted with a new feature, >>> so even if there are no consumers from the EDK II repos, >>> the feature can still be tested as the EDK II repos are >>> maintained. A third option is for community members to >>> provide Tested-by responses to the feature along with >>> statements in the Bugzilla that clearly documents how the >>> the feature was tested. >>> >>> Best regards, >>> >>> Mike >>> >>> > -Original Message- >>> > From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> >>> > [mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>] On Behalf Of >>> > Laszlo Ersek >>> > Sent: Friday, August 16, 2019 12:39 PM >>> > To: vit9...@protonmail.com <mailto:vit9...@protonmail.com> >>> > Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>; >>> > leif.lindh...@linaro.org <mailto:leif.lindh...@linaro.org>; >>> > af...@apple.com <mailto:af...@apple.com> >>> > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add >>> > STATIC_ASSERT macro >>> > >>> > On 08/16/19 19:23, vit9...@protonmail.com <mailto:vit9...@protonmail.com> >>> > wrote: >>> > > Laszlo, >>> > > >>> > > I have already mentioned that the documentation is >>> > sufficient as >>> > > _Static_assert is C standard >>> > >>> > Yes, in a release of the ISO C standard that edk2 does >>> > not target. >>> > >>> > In addition, edk2 already has several restrictions in >>> > place against standards-conformant code. (Such as bit- >>> > shifting of UINT64 values, initialization of structures >>> > with automatic storage duration, structure assignment, >>> > maybe more.) >>> > >>> > > so I do not plan to make a V3 for this patch. >>> > >>> > I find that regrettable. >>> > >>> > > The patch is merge ready. >>> > >>> > Such statements are usually made when people that >>> > comment on a patch arrive at a consensus. The patch may >>> > be merge-ready from your perspective and from Mike's. >>> > It is not merge-ready from my perspective. >>> > I hope I'm allowed to comment (constructively) on >>> > patches that aren't strictly aimed at the subsystems I >>> > co-maintain. >>> > >>> > > As for usage examples I have an opposing opinion to >>> > yours and believe >>> > > it is based on very good reasons. Not using >>> > STATIC_ASSERT in the >>> > > current release will make the feature optionally >>> > available and let >>> > > people test it in their setups. >>> > >>> > Not using STATIC_ASSERT in the current stable release >>> > makes the STATIC_ASSERT macro definition *dead code* in >>> > edk2 proper. I understand that edk2 is a "kit", and >>> > quite explicitly caters to out-of-tree platforms. >>> > That's not a positive trait of edk2 however; it's a >>> > negative one, in my judgement. Whatever we add to the >>> > core of edk2, we should exercise as diligently as we >>> > can *inside* of edk2. >>> > >>> > > In case they notice it does not work for them they >>> > will have 3 months >>> > > grace period to report it to us and consider making a >>> > change. >>> > >>> > That is what the feature freezes are for. The feature >>> > is reviewed before the soft feature freeze, merged (at >>> > the latest) during the soft feature freeze, and bugs >>> > can still be fixed during the hard feature freeze. The >>> > community is expected to test diligently during the >>> > hard feature freeze. >>> > Perhaps we should extend the hard feature freeze. >>> > >>> > My problem is not that the change is no
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
> On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io
> wrote:
>
> Mike,
>
> I missed your message while writing mine, but I am afraid I disagree with the
> functional macro usage for this feature.
>
> I explicitly quoted C standard static_assert definition in one of my previous
> messages, and I want EDK II to be as close to standard C as possible.
>
> This will avoid a lot of confusion for newcomers and will let us later adopt
> a more flexible single and double argument interface when it gets
> standardised.
>
> For these reasons altogether, I am not positive the macro could get a doxygen
> documentation as it is not designed to have any arguments in the first place.
>
Vitaly,
I don't understand your logic? It is always possible to write a comment in C
code?
In terms of the C standard and the EFI type system we kind of have a long
history of how the code ended up like it is. The (U)EFI spec defined its own
type system (and ABI) as a way of specifying interoperability so the code got
built on top of that. 20 years ago we shied away from having and EFI code base
produce definitions of standard C things as we wanted to make it easier to
import chunks of code in OS loaders that needed to get ported to EFI from lots
of different vendors. Also one of the early compilers that we standardized on
was VC2003 and that does not even fully support C99. For some reason it seems
VC2008 was also a popular target for some time. I don't think VC++ got around
to C99 until 2013/2015. So that is kind how the edk2 ended up with its own type
system.
I'm all for modernization of the C code as long we are thoughtful about
compatibility. For example I still see that VS2008 is a supported
BaseTools/Conf/tools_def.template.
Thanks,
Andrew Fish
> Best wishes,
> Vitaly
>
> On сб, авг. 17, 2019 at 00:04, Kinney, Michael D <mailto:michael.d.kin...@intel.com>> wrote:
>>
>> Laszlo,
>>
>> I agree that better comments/documentation of STATIC_ASSERT()
>> for EDK II usages is required. For example, EDK II defines
>> the ASSERT() macro which is based on the standard C function
>> assert(), but we still document it fully for EDK II usage.
>>
>> /**
>> Macro that calls DebugAssert() if an expression evaluates to FALSE.
>>
>> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
>> bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
>> expression specified by Expression. If Expression evaluates to FALSE, then
>> DebugAssert() is called passing in the source filename, source line number,
>> and Expression.
>>
>> @param Expression Boolean expression.
>>
>> **/
>> #if !defined(MDEPKG_NDEBUG)
>> #define ASSERT(Expression) \
>> do { \
>> if (DebugAssertEnabled ()) { \
>> if (!(Expression)) { \
>> _ASSERT (Expression); \
>> ANALYZER_UNREACHABLE (); \
>> } \
>> } \
>> } while (FALSE)
>> #else
>> #define ASSERT(Expression)
>> #endif
>>
>> I would like to see the macro documentation for
>> STATIC_ASSERT() with the Doxygen style description of the
>> parameters. The fact I asked if STATIC_ASSERT() supported
>> the 2nd message parameter should have been a trigger
>> for me to ask for the more complete macro comment block.
>> The fact that this macro can be directly mapped to
>> built in compiler name makes the implementation simple,
>> but other implementations are possible for compilers
>> that do not support this feature directly. This is why
>> the complete description of the EDK II version is required.
>>
>> I would like to see a V3 with the complete description.
>>
>> In general, I agree it is better if there is code that
>> uses a new feature in the code base, so the feature can
>> be tested. A second option we can consider going forward
>> is for unit test code to be submitted with a new feature,
>> so even if there are no consumers from the EDK II repos,
>> the feature can still be tested as the EDK II repos are
>> maintained. A third option is for community members to
>> provide Tested-by responses to the feature along with
>> statements in the Bugzilla that clearly documents how the
>> the feature was tested.
>>
>> Best regards,
>>
>> Mike
>>
>> > -Original Message-
>> > From: devel@edk2.groups.io
>> > [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
>> > Sent: Friday, August 16, 2019 12:39 PM
>> > To: vit9...@protonmail.com
>> > Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
>> > af...@apple.com
>> > Subje
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 2019-08-16 15:40, Vitaly Cheptsov via Groups.Io wrote: > I missed your message while writing mine, but I am afraid I disagree > with the functional macro usage for this feature. > > I explicitly quoted C standard static_assert definition in one of my > previous messages, and I want EDK II to be as close to standard C as > possible. > Choosing a random message in this thread to comment. We could also migrate the existing uses of __STATIC_ASSERT in BaseTools to the new STATIC_ASSERT: BaseTools/Source/C/Common/PcdValueCommon.h:22:#define __STATIC_ASSERT static_assert BaseTools/Source/C/Common/PcdValueCommon.h:24:#define __STATIC_ASSERT _Static_assert Binary file BaseTools/Source/Python/Workspace/DscBuildData.pyc matches BaseTools/Source/Python/Workspace/DscBuildData.py:2037: CApp = CApp + '__STATIC_ASSERT(sizeof(%s_%s_INIT_Value) < %d * sizeof(%s), "Pcd %s.%s Value in Dec exceed the array capability %s"); // From %s Line %s \n ' % (Pcd.TokenSpaceGuidCName, Pcd.TokenCName,pcdarraysize,Pcd.BaseDatumType,Pcd.TokenSpaceGuidCName, Pcd.TokenCName,Pcd.DatumType,Pcd.DefaultValueFromDecInfo[0],Pcd.DefaultValueFromDecInfo[1]) BaseTools/Source/Python/Workspace/DscBuildData.py:2042: CApp = CApp + '__STATIC_ASSERT(%d < %d * sizeof(%s), "Pcd %s.%s Value in Dec exceed the array capability %s"); // From %s Line %s \n' % (ValueSize,pcdarraysize,Pcd.BaseDatumType,Pcd.TokenSpaceGuidCName, Pcd.TokenCName,Pcd.DatumType,Pcd.DefaultValueFromDecInfo[0],Pcd.DefaultValueFromDecInfo[1]) -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45865): https://edk2.groups.io/g/devel/message/45865 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Mike,
I missed your message while writing mine, but I am afraid I disagree with the
functional macro usage for this feature.
I explicitly quoted C standard static_assert definition in one of my previous
messages, and I want EDK II to be as close to standard C as possible.
This will avoid a lot of confusion for newcomers and will let us later adopt a
more flexible single and double argument interface when it gets standardised.
For these reasons altogether, I am not positive the macro could get a doxygen
documentation as it is not designed to have any arguments in the first place.
Best wishes,
Vitaly
On сб, авг. 17, 2019 at 00:04, Kinney, Michael D
wrote:
> Laszlo,
>
> I agree that better comments/documentation of STATIC_ASSERT()
> for EDK II usages is required. For example, EDK II defines
> the ASSERT() macro which is based on the standard C function
> assert(), but we still document it fully for EDK II usage.
>
> /**
> Macro that calls DebugAssert() if an expression evaluates to FALSE.
>
> If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
> bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
> expression specified by Expression. If Expression evaluates to FALSE, then
> DebugAssert() is called passing in the source filename, source line number,
> and Expression.
>
> @param Expression Boolean expression.
>
> **/
> #if !defined(MDEPKG_NDEBUG)
> #define ASSERT(Expression) \
> do { \
> if (DebugAssertEnabled ()) { \
> if (!(Expression)) { \
> _ASSERT (Expression); \
> ANALYZER_UNREACHABLE (); \
> } \
> } \
> } while (FALSE)
> #else
> #define ASSERT(Expression)
> #endif
>
> I would like to see the macro documentation for
> STATIC_ASSERT() with the Doxygen style description of the
> parameters. The fact I asked if STATIC_ASSERT() supported
> the 2nd message parameter should have been a trigger
> for me to ask for the more complete macro comment block.
> The fact that this macro can be directly mapped to
> built in compiler name makes the implementation simple,
> but other implementations are possible for compilers
> that do not support this feature directly. This is why
> the complete description of the EDK II version is required.
>
> I would like to see a V3 with the complete description.
>
> In general, I agree it is better if there is code that
> uses a new feature in the code base, so the feature can
> be tested. A second option we can consider going forward
> is for unit test code to be submitted with a new feature,
> so even if there are no consumers from the EDK II repos,
> the feature can still be tested as the EDK II repos are
> maintained. A third option is for community members to
> provide Tested-by responses to the feature along with
> statements in the Bugzilla that clearly documents how the
> the feature was tested.
>
> Best regards,
>
> Mike
>
>> -Original Message-
>> From: devel@edk2.groups.io
>> [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
>> Sent: Friday, August 16, 2019 12:39 PM
>> To: vit9...@protonmail.com
>> Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
>> af...@apple.com
>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>> STATIC_ASSERT macro
>>
>> On 08/16/19 19:23, vit9...@protonmail.com wrote:
>> > Laszlo,
>> >
>> > I have already mentioned that the documentation is
>> sufficient as
>> > _Static_assert is C standard
>>
>> Yes, in a release of the ISO C standard that edk2 does
>> not target.
>>
>> In addition, edk2 already has several restrictions in
>> place against standards-conformant code. (Such as bit-
>> shifting of UINT64 values, initialization of structures
>> with automatic storage duration, structure assignment,
>> maybe more.)
>>
>> > so I do not plan to make a V3 for this patch.
>>
>> I find that regrettable.
>>
>> > The patch is merge ready.
>>
>> Such statements are usually made when people that
>> comment on a patch arrive at a consensus. The patch may
>> be merge-ready from your perspective and from Mike's.
>> It is not merge-ready from my perspective.
>> I hope I'm allowed to comment (constructively) on
>> patches that aren't strictly aimed at the subsystems I
>> co-maintain.
>>
>> > As for usage examples I have an opposing opinion to
>> yours and believe
>> > it is based on very good reasons. Not using
>> STATIC_ASSERT in the
>> > current release will make the feature optionally
>> available and let
>> > people test it in their setups.
>>
>> Not using STATIC_ASSERT in the curren
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Laszlo, I am very glad to you for expressing a different opinion as this lets me view the situation from different angles. I understand your concerns, and believe that most of them should actually be addressed in a way you explain. In fact, I plan to submit more patches myself for everyone's benefit. The exact situation with static assertions is that they are not coming too early, but actually too late. We have been using static assertions in UEFI code for quite some time already, and I believe we are not alone. All of us will benefit from legacy code removal once this patch lands upstream. For your claim that this code is not well tested I should mention that the patch is based on one of the open-source projects I maintain, which everyone can track, and which I believe have gotten reasonable attention from different people with different compilers. For dead code I believe that in EDK II we do not have a good definition for that term as normally done in serious industrial projects like aerospace or military that have no dead code requirement in their SDL. Primarily because EDK II is a library for others to rely on, it is not a self contained system where dead code term is usually defined, standardised and verified against. Whether it is liked or not, the fact EDK II gets continual development is only because different companies, academia, and individuals use its code. I feel bad for these people having to fork, and believe that most value in EDK is what it gives to the outside, not the inside. So supporting a new interface a number of projects use and need makes most sense to me. I do not want to make more changes to core code for multiple reasons as you see above. One of them indeed being some necessary discussion for the use inside EDK II. But I do not believe this a good stopper from giving a working interface to others, which unlike EDK II, actually have defined compilers, infrastructure, and requirements. Hopefully I pointed out to enough reasons to leave you with some doubts and permit this patch to land in as an exception from your personal standpoint. Thank you for understanding and being constructive. Cheers, Vitaly On пт, авг. 16, 2019 at 22:38, Laszlo Ersek wrote: > On 08/16/19 19:23, vit9...@protonmail.com wrote: >> Laszlo, >> >> I have already mentioned that the documentation is sufficient as >> _Static_assert is C standard > > Yes, in a release of the ISO C standard that edk2 does not target. > > In addition, edk2 already has several restrictions in place against > standards-conformant code. (Such as bit-shifting of UINT64 values, > initialization of structures with automatic storage duration, structure > assignment, maybe more.) > >> so I do not plan to make a V3 for this patch. > > I find that regrettable. > >> The patch is merge ready. > > Such statements are usually made when people that comment on a patch > arrive at a consensus. The patch may be merge-ready from your > perspective and from Mike's. It is not merge-ready from my perspective. > I hope I'm allowed to comment (constructively) on patches that aren't > strictly aimed at the subsystems I co-maintain. > >> As for usage examples I have an opposing opinion to yours and believe >> it is based on very good reasons. Not using STATIC_ASSERT in the >> current release will make the feature optionally available and let >> people test it in their setups. > > Not using STATIC_ASSERT in the current stable release makes the > STATIC_ASSERT macro definition *dead code* in edk2 proper. I understand > that edk2 is a "kit", and quite explicitly caters to out-of-tree > platforms. That's not a positive trait of edk2 however; it's a negative > one, in my judgement. Whatever we add to the core of edk2, we should > exercise as diligently as we can *inside* of edk2. > >> In case they notice it does not work for them they will have 3 months >> grace period to report it to us and consider making a change. > > That is what the feature freezes are for. The feature is reviewed before > the soft feature freeze, merged (at the latest) during the soft feature > freeze, and bugs can still be fixed during the hard feature freeze. The > community is expected to test diligently during the hard feature freeze. > Perhaps we should extend the hard feature freeze. > > My problem is not that the change is not "in your face". I'm all for > avoiding regressions. My problem is that the code is dead and untestable > without platform changes, even though it could be put to great use in > core code at once. If you think that's too risky, this close to the > stable tag, then one solution is to resubmit at the beginning of the > next development cycle (again with additional patches that utilize the > STATIC_ASSERT macro at once). Developers will then have close to three > months to report and fix issues. > > Another solution would be to conditionally keep VERIFY_SIZE_OF, vs. > using STATIC_ASSERT, for expressing the build-time invariants.
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Laszlo,
I agree that better comments/documentation of STATIC_ASSERT()
for EDK II usages is required. For example, EDK II defines
the ASSERT() macro which is based on the standard C function
assert(), but we still document it fully for EDK II usage.
/**
Macro that calls DebugAssert() if an expression evaluates to FALSE.
If MDEPKG_NDEBUG is not defined and the DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED
bit of PcdDebugProperyMask is set, then this macro evaluates the Boolean
expression specified by Expression. If Expression evaluates to FALSE, then
DebugAssert() is called passing in the source filename, source line number,
and Expression.
@param Expression Boolean expression.
**/
#if !defined(MDEPKG_NDEBUG)
#define ASSERT(Expression)\
do {\
if (DebugAssertEnabled ()) { \
if (!(Expression)) {\
_ASSERT (Expression); \
ANALYZER_UNREACHABLE (); \
} \
} \
} while (FALSE)
#else
#define ASSERT(Expression)
#endif
I would like to see the macro documentation for
STATIC_ASSERT() with the Doxygen style description of the
parameters. The fact I asked if STATIC_ASSERT() supported
the 2nd message parameter should have been a trigger
for me to ask for the more complete macro comment block.
The fact that this macro can be directly mapped to
built in compiler name makes the implementation simple,
but other implementations are possible for compilers
that do not support this feature directly. This is why
the complete description of the EDK II version is required.
I would like to see a V3 with the complete description.
In general, I agree it is better if there is code that
uses a new feature in the code base, so the feature can
be tested. A second option we can consider going forward
is for unit test code to be submitted with a new feature,
so even if there are no consumers from the EDK II repos,
the feature can still be tested as the EDK II repos are
maintained. A third option is for community members to
provide Tested-by responses to the feature along with
statements in the Bugzilla that clearly documents how the
the feature was tested.
Best regards,
Mike
> -Original Message-
> From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of Laszlo Ersek
> Sent: Friday, August 16, 2019 12:39 PM
> To: vit9...@protonmail.com
> Cc: devel@edk2.groups.io; leif.lindh...@linaro.org;
> af...@apple.com
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
>
> On 08/16/19 19:23, vit9...@protonmail.com wrote:
> > Laszlo,
> >
> > I have already mentioned that the documentation is
> sufficient as
> > _Static_assert is C standard
>
> Yes, in a release of the ISO C standard that edk2 does
> not target.
>
> In addition, edk2 already has several restrictions in
> place against standards-conformant code. (Such as bit-
> shifting of UINT64 values, initialization of structures
> with automatic storage duration, structure assignment,
> maybe more.)
>
> > so I do not plan to make a V3 for this patch.
>
> I find that regrettable.
>
> > The patch is merge ready.
>
> Such statements are usually made when people that
> comment on a patch arrive at a consensus. The patch may
> be merge-ready from your perspective and from Mike's.
> It is not merge-ready from my perspective.
> I hope I'm allowed to comment (constructively) on
> patches that aren't strictly aimed at the subsystems I
> co-maintain.
>
> > As for usage examples I have an opposing opinion to
> yours and believe
> > it is based on very good reasons. Not using
> STATIC_ASSERT in the
> > current release will make the feature optionally
> available and let
> > people test it in their setups.
>
> Not using STATIC_ASSERT in the current stable release
> makes the STATIC_ASSERT macro definition *dead code* in
> edk2 proper. I understand that edk2 is a "kit", and
> quite explicitly caters to out-of-tree platforms.
> That's not a positive trait of edk2 however; it's a
> negative one, in my judgement. Whatever we add to the
> core of edk2, we should exercise as diligently as we
> can *inside* of edk2.
>
> > In case they notice it does not work for them they
> will have 3 months
> > grace period to report it to us and consider making a
> change.
>
> That is what the feature freezes are for. The feature
> is reviewed before the soft feature freeze, merged (at
> the latest) during the soft feature freeze, and bugs
> can still be fixed during the hard feature freeze. The
> community is expected to test diligently during the
> hard feature freeze.
> Perhaps we should extend the hard feature freeze.
>
> My proble
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 08/16/19 21:38, Laszlo Ersek wrote: > I understand that edk2 is a "kit", and quite explicitly caters to > out-of-tree platforms. That's not a positive trait of edk2 however; > it's a negative one, in my judgement. To clarify... I didn't mean that edk2 should willfully ignore dependent platforms. Harmony between universal edk2 code and dependent platforms is important. I meant that more platform code should live inside the edk2 project. Again, this is a personal opinion. Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45855): https://edk2.groups.io/g/devel/message/45855 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 08/15/19 18:08, Michael D Kinney wrote: > Reviewed-by: Michael D Kinney To summarize: personally, I disgree, but I can accept if the patch goes in with Mike's R-b. Thanks, Laszlo >> -Original Message- >> From: devel@edk2.groups.io >> [mailto:devel@edk2.groups.io] On Behalf Of vit9696 via >> Groups.Io >> Sent: Tuesday, August 13, 2019 1:17 AM >> To: devel@edk2.groups.io >> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add >> STATIC_ASSERT macro >> >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 >> >> Provide a macro for compile time assertions. >> Equivalent to C11 static_assert macro from assert.h. >> >> Signed-off-by: Vitaly Cheptsov >> --- >> MdePkg/Include/Base.h | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/MdePkg/Include/Base.h >> b/MdePkg/Include/Base.h index >> ce20b5f01dce..f85f7028a262 100644 >> --- a/MdePkg/Include/Base.h >> +++ b/MdePkg/Include/Base.h >> @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST; >> #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)- >>> Field)) #endif >> >> +/// >> +/// Portable definition for compile time assertions. >> +/// Equivalent to C11 static_assert macro from >> assert.h. >> +/// Takes condtion and error message as its arguments. >> +/// >> +#ifdef _MSC_EXTENSIONS >> + #define STATIC_ASSERT static_assert >> +#else >> + #define STATIC_ASSERT _Static_assert >> +#endif >> + >> /** >>Macro that returns a pointer to the data structure >> that contains a specified field of >>that data structure. This is a lightweight method >> to hide information by placing a >> -- >> 2.20.1 (Apple Git-117) >> >> >> -=-=-=-=-=-= >> Groups.io Links: You receive all messages sent to this >> group. >> >> View/Reply Online (#45503): >> https://edk2.groups.io/g/devel/message/45503 >> Mute This Topic: https://groups.io/mt/32850582/1643496 >> Group Owner: devel+ow...@edk2.groups.io >> Unsubscribe: https://edk2.groups.io/g/devel/unsub >> [michael.d.kin...@intel.com] >> -=-=-=-=-=-= > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45851): https://edk2.groups.io/g/devel/message/45851 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 08/16/19 19:23, vit9...@protonmail.com wrote: > Laszlo, > > I have already mentioned that the documentation is sufficient as > _Static_assert is C standard Yes, in a release of the ISO C standard that edk2 does not target. In addition, edk2 already has several restrictions in place against standards-conformant code. (Such as bit-shifting of UINT64 values, initialization of structures with automatic storage duration, structure assignment, maybe more.) > so I do not plan to make a V3 for this patch. I find that regrettable. > The patch is merge ready. Such statements are usually made when people that comment on a patch arrive at a consensus. The patch may be merge-ready from your perspective and from Mike's. It is not merge-ready from my perspective. I hope I'm allowed to comment (constructively) on patches that aren't strictly aimed at the subsystems I co-maintain. > As for usage examples I have an opposing opinion to yours and believe > it is based on very good reasons. Not using STATIC_ASSERT in the > current release will make the feature optionally available and let > people test it in their setups. Not using STATIC_ASSERT in the current stable release makes the STATIC_ASSERT macro definition *dead code* in edk2 proper. I understand that edk2 is a "kit", and quite explicitly caters to out-of-tree platforms. That's not a positive trait of edk2 however; it's a negative one, in my judgement. Whatever we add to the core of edk2, we should exercise as diligently as we can *inside* of edk2. > In case they notice it does not work for them they will have 3 months > grace period to report it to us and consider making a change. That is what the feature freezes are for. The feature is reviewed before the soft feature freeze, merged (at the latest) during the soft feature freeze, and bugs can still be fixed during the hard feature freeze. The community is expected to test diligently during the hard feature freeze. Perhaps we should extend the hard feature freeze. My problem is not that the change is not "in your face". I'm all for avoiding regressions. My problem is that the code is dead and untestable without platform changes, even though it could be put to great use in core code at once. If you think that's too risky, this close to the stable tag, then one solution is to resubmit at the beginning of the next development cycle (again with additional patches that utilize the STATIC_ASSERT macro at once). Developers will then have close to three months to report and fix issues. Another solution would be to conditionally keep VERIFY_SIZE_OF, vs. using STATIC_ASSERT, for expressing the build-time invariants. The default would be STATIC_ASSERT. Should it break, people could immediately switch back to VERIFY_SIZE_OF, without disruption to their workflows. We've done similar things in OvmfPkg in the past. For example: - USE_LEGACY_ISA_STACK (commit a06810229618 / commit 562688707145), - USE_OLD_BDS (commit 79c098b6d25d / commit dd43486577b3), - USE_OLD_PCI_HOST (commit 4014885ffdfa / commit cef83a3050e5). > This will also give them 3 months grace period of VERIFY_SIZE_OF macro > removal in favour of STATIC_ASSERT. Making the change now will let > people do seamless transition to the new feature and will avoid > obstacles you are currently trying to create. Please stop making claims in bad faith. I'm not trying to "create obstacles". I'm a fan of STATIC_ASSERT. I'm not a fan of dead code. > Thus STATIC_ASSERT usage and VERIFY_SIZE_OF removal must both be > separate patchsets with potentially separate BZs. > > Thanks for understanding, Why are you presenting this as a done deal? The v2 patch was submitted three days ago, IIUC. Also, I wish we could have this discussion without condescension. Thanks, Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45850): https://edk2.groups.io/g/devel/message/45850 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Laszlo, I have already mentioned that the documentation is sufficient as _Static_assert is C standard, so I do not plan to make a V3 for this patch. The patch is merge ready. As for usage examples I have an opposing opinion to yours and believe it is based on very good reasons. Not using STATIC_ASSERT in the current release will make the feature optionally available and let people test it in their setups. In case they notice it does not work for them they will have 3 months grace period to report it to us and consider making a change. This will also give them 3 months grace period of VERIFY_SIZE_OF macro removal in favour of STATIC_ASSERT. Making the change now will let people do seamless transition to the new feature and will avoid obstacles you are currently trying to create. Thus STATIC_ASSERT usage and VERIFY_SIZE_OF removal must both be separate patchsets with potentially separate BZs. Thanks for understanding, Vitaly > 16 авг. 2019 г., в 19:33, Laszlo Ersek написал(а): > > > On 08/15/19 03:59, Gao, Liming wrote: >> Vitaly: >> As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose >> this patch plan to catch this stable tag? >> If yes, please ask the feedback from Tianocore Stewards. I have cc this >> patch to all Stewards. > > If a feature patch (or series) is fully reviewed before the soft feature > freeze (by the respective package maintainers), it can be merged during > the soft feature freeze. > > However, I don't think this patch is mature enough for that. As I've > just said up-thread, I'd like to see STATIC_ASSERT being put to use at > once (in the same series, not in the same patch). In addition, the > documentation should be improved (the (constant-expression , > string-literal) parameter list seems absent, or at least insufficiently > documented). > > In turn, I doubt a v3 posting could be reviewed with enough care before > we enter the soft feature freeze. I'd suggest to submit the v3 series as > soon as we start the next development cycle. > > Thanks > Laszlo > >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, >> Jiewen >> Sent: Thursday, August 15, 2019 9:05 AM >> To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D >> >> Cc: Laszlo Ersek >> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro >> >> Good input. >> I think we should separate the work to convert all EDKII code to use >> STATIC_ASSERT. >> We can do that work once we add STATIC_ASSERT. >> >> I recommend: >> >> 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla >> >> 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove >> VERIFY_SIZE_OF – the other patch and the other Bugzilla >> >> 3) Step 3: Scan the rest, if there is need. – Another patch and another >> Bugzilla >> >> Thank you >> Yao Jiewen >> >> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> >> [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io >> Sent: Thursday, August 15, 2019 12:23 AM >> To: Kinney, Michael D >> mailto:michael.d.kin...@intel.com>> >> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek >> mailto:ler...@redhat.com>> >> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro >> >> >> Michael, Liming, Laszlo, >> >> Static assertions via _Static_assert are standard C11 functionality, thus >> any at least C11 (ISO/IEC 9899 2011) conforming compiler is required to >> support the second argument with the diagnostic description. >> >> The notation without the message currently is only present in C++, not in C, >> thus the two-argument notation is the only allowed notation for >> _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. >> >> In the bottom of this message I included a quote from C17 for the relevant >> section (6.7.10). >> >> GCC and CLANG (including Xcode) appear to be conforming to the standard for >> this section, and MSVC compiler static_assert extension also supports the >> diagnostic message argument. This is pretty much all we care about. >> >> As for examples, I see little reason to clarify STATIC_ASSERT behaviour >> outside of the standard reference in its description and actual usage in the >> source code, but can do that just fine if you think that it may help >> somebody. >> >> I fully agree that VERIFY_SIZE_OF usage should be converted to >> STATIC_ASSERT, and in fact I also suggest VERIFY_SIZE_OF to be entirely
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
On 08/15/19 03:59, Gao, Liming wrote: > Vitaly: > As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose > this patch plan to catch this stable tag? > If yes, please ask the feedback from Tianocore Stewards. I have cc this > patch to all Stewards. If a feature patch (or series) is fully reviewed before the soft feature freeze (by the respective package maintainers), it can be merged during the soft feature freeze. However, I don't think this patch is mature enough for that. As I've just said up-thread, I'd like to see STATIC_ASSERT being put to use at once (in the same series, not in the same patch). In addition, the documentation should be improved (the (constant-expression , string-literal) parameter list seems absent, or at least insufficiently documented). In turn, I doubt a v3 posting could be reviewed with enough care before we enter the soft feature freeze. I'd suggest to submit the v3 series as soon as we start the next development cycle. Thanks Laszlo > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, > Jiewen > Sent: Thursday, August 15, 2019 9:05 AM > To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D > > Cc: Laszlo Ersek > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro > > Good input. > I think we should separate the work to convert all EDKII code to use > STATIC_ASSERT. > We can do that work once we add STATIC_ASSERT. > > I recommend: > > 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla > > 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove > VERIFY_SIZE_OF – the other patch and the other Bugzilla > > 3) Step 3: Scan the rest, if there is need. – Another patch and another > Bugzilla > > Thank you > Yao Jiewen > > From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> > [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io > Sent: Thursday, August 15, 2019 12:23 AM > To: Kinney, Michael D > mailto:michael.d.kin...@intel.com>> > Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek > mailto:ler...@redhat.com>> > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro > > > Michael, Liming, Laszlo, > > Static assertions via _Static_assert are standard C11 functionality, thus any > at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support > the second argument with the diagnostic description. > > The notation without the message currently is only present in C++, not in C, > thus the two-argument notation is the only allowed notation for > _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. > > In the bottom of this message I included a quote from C17 for the relevant > section (6.7.10). > > GCC and CLANG (including Xcode) appear to be conforming to the standard for > this section, and MSVC compiler static_assert extension also supports the > diagnostic message argument. This is pretty much all we care about. > > As for examples, I see little reason to clarify STATIC_ASSERT behaviour > outside of the standard reference in its description and actual usage in the > source code, but can do that just fine if you think that it may help somebody. > > I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, > and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. > This should be fairly costless, as apparently it is only used in Base.h and > MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in > the same patch set. > > As for select ASSERT usage switching to STATIC_ASSERT, this would also be > great, as let us be honest, the use of ASSERT in EDK II codebase is very > questioning. In fact, this was one of the reasons we introduced our own > static assertions some time ago. However, fixing up all broken assertions is > unlikely a best place to fit into this patchset, but I can surely add a few > examples, in case somebody points them out. This will be useful for reference > purposes and may help the maintainers to get a better idea when static > assertions are to be used. > > Looking forward to hearing your opinions. > > Best regards, > Vitaly > > > 6.7.10 Static assertions > > Syntax > 1 static_assert-declaration: > _Static_assert ( constant-expression , string-literal ) ; > > Constraints > 2 The constant expression shall compare unequal to 0. > > Semantics > 3 The constant expression shall be an integer constant expression. If the > value of the constant expression compares unequal to 0, the declaration has > no effect. Otherwise, the constraint is violated and
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
TYPE.
>>
>> **/
>> #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8
>> _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
>>
>> //
>> // Verify that ProcessorBind.h produced UEFI Data Types that are compliant
>> with
>> // Section 2.3.1 of the UEFI 2.3 Specification.
>> //
>> VERIFY_SIZE_OF (BOOLEAN, 1);
>> VERIFY_SIZE_OF (INT8, 1);
>> VERIFY_SIZE_OF (UINT8, 1);
>> VERIFY_SIZE_OF (INT16, 2);
>> VERIFY_SIZE_OF (UINT16, 2);
>> VERIFY_SIZE_OF (INT32, 4);
>> VERIFY_SIZE_OF (UINT32, 4);
>> VERIFY_SIZE_OF (INT64, 8);
>> VERIFY_SIZE_OF (UINT64, 8);
>> VERIFY_SIZE_OF (CHAR8, 1);
>> VERIFY_SIZE_OF (CHAR16, 2);
>>
>> //
>> // The following three enum types are used to verify that the compiler
>> // configuration for enum types is compliant with Section 2.3.1 of the
>> // UEFI 2.3 Specification. These enum types and enum values are not
>> // intended to be used. A prefix of '__' is used avoid conflicts with
>> // other types.
>> //
>> typedef enum {
>> __VerifyUint8EnumValue = 0xff
>> } __VERIFY_UINT8_ENUM_SIZE;
>>
>> typedef enum {
>> __VerifyUint16EnumValue = 0x
>> } __VERIFY_UINT16_ENUM_SIZE;
>>
>> typedef enum {
>> __VerifyUint32EnumValue = 0x
>> } __VERIFY_UINT32_ENUM_SIZE;
>>
>> VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
>> VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
>> VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
>>
>> A couple examples. Do all the compilers support the message parameter too?
>>
>> STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI
>> Specification Data Type requirements")
>> STATIC_ASSERT (sizeof (UINT16) == 2, "sizeof (UINT16) does not meet UEFI
>> Specification Data Type requirements")
>> STATIC_ASSERT (sizeof (INT32) == 4, "sizeof (INT32) does not meet UEFI
>> Specification Data Type requirements")
>> STATIC_ASSERT (sizeof (CHAR16) == 2, "sizeof (CHAR16) does not meet UEFI
>> Specification Data Type requirements")
>> STATIC_ASSERT (sizeof (__VERIFY_UINT8_ENUM_SIZE) == 4, "Size of enum does
>> not meet UEFI Specification Data Type requirements")
>> STATIC_ASSERT (sizeof (__VERIFY_UINT32_ENUM_SIZE) == 4, "Size of enum does
>> not meet UEFI Specification Data Type requirements")
>>
>> Thanks,
>>
>> Mike
>>
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
>>> On Behalf Of Liming Gao
>>> Sent: Wednesday, August 14, 2019 6:50 AM
>>> To: devel@edk2.groups.io; vit9...@protonmail.com
>>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>>> STATIC_ASSERT macro
>>>
>>> Can you add the sample usage of new macro STATIC_ASSERT?
>>>
>>> Or, give the link of static_assert or _Static_assert.
>>>
>>> If so, the developer knows how to use them in source
>>> code.
>>>
>>> Thanks
>>> Liming
>>>> -Original Message-
>>>> From: devel@edk2.groups.io
>>> [mailto:devel@edk2.groups.io] On Behalf Of
>>>> vit9696 via Groups.Io
>>>> Sent: Tuesday, August 13, 2019 4:17 PM
>>>> To: devel@edk2.groups.io
>>>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
>>> STATIC_ASSERT macro
>>>>
>>>>
>>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
>>>>
>>>> Provide a macro for compile time assertions.
>>>> Equivalent to C11 static_assert macro from assert.h.
>>>>
>>>> Signed-off-by: Vitaly Cheptsov
>>>
>>>> ---
>>>> MdePkg/Include/Base.h | 11 +++
>>>> 1 file changed, 11 insertions(+)
>>>>
>>>> diff --git a/MdePkg/Include/Base.h
>>> b/MdePkg/Include/Base.h index
>>>> ce20b5f01dce..f85f7028a262 100644
>>>> --- a/MdePkg/Include/Base.h
>>>> +++ b/MdePkg/Include/Base.h
>>>> @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST;
>>> #define
>>>> OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
>>> #endif
>>>>
>>>> +///
>>>> +/// Portable definition for compile time assertions.
>>>> +/// Equivalent to C11 static_assert macro from
>>> assert.h.
>>>> +/// Takes condtion and error message as its
>>> arguments.
>>>> +///
>>>> +#ifdef _MSC_EXTENSIONS
>>>> + #define STATIC_ASSERT static_assert #else
>>>> + #define STATIC_ASSERT _Static_assert #endif
>>>> +
>>>> /**
>>>> Macro that returns a pointer to the data structure
>>> that contains a specified field of
>>>> that data structure. This is a lightweight method
>>> to hide
>>>> information by placing a
>>>> --
>>>> 2.20.1 (Apple Git-117)
>>>>
>>>>
>>>> -=-=-=-=-=-=
>>>> Groups.io Links: You receive all messages sent to this
>>> group.
>>>>
>>>> View/Reply Online (#45503):
>>>> https://edk2.groups.io/g/devel/message/45503
>>>> Mute This Topic: https://groups.io/mt/32850582/1759384
>>>> Group Owner: devel+ow...@edk2.groups.io
>>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>>> [liming@intel.com] -=-=-=-=-=-=
>>>
>>>
>>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#45827): https://edk2.groups.io/g/devel/message/45827
Mute This Topic: https://groups.io/mt/32850582/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Reviewed-by: Michael D Kinney Mike > -Original Message- > From: devel@edk2.groups.io > [mailto:devel@edk2.groups.io] On Behalf Of vit9696 via > Groups.Io > Sent: Tuesday, August 13, 2019 1:17 AM > To: devel@edk2.groups.io > Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add > STATIC_ASSERT macro > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 > > Provide a macro for compile time assertions. > Equivalent to C11 static_assert macro from assert.h. > > Signed-off-by: Vitaly Cheptsov > --- > MdePkg/Include/Base.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/MdePkg/Include/Base.h > b/MdePkg/Include/Base.h index > ce20b5f01dce..f85f7028a262 100644 > --- a/MdePkg/Include/Base.h > +++ b/MdePkg/Include/Base.h > @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST; > #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)- > >Field)) #endif > > +/// > +/// Portable definition for compile time assertions. > +/// Equivalent to C11 static_assert macro from > assert.h. > +/// Takes condtion and error message as its arguments. > +/// > +#ifdef _MSC_EXTENSIONS > + #define STATIC_ASSERT static_assert > +#else > + #define STATIC_ASSERT _Static_assert > +#endif > + > /** >Macro that returns a pointer to the data structure > that contains a specified field of >that data structure. This is a lightweight method > to hide information by placing a > -- > 2.20.1 (Apple Git-117) > > > -=-=-=-=-=-= > Groups.io Links: You receive all messages sent to this > group. > > View/Reply Online (#45503): > https://edk2.groups.io/g/devel/message/45503 > Mute This Topic: https://groups.io/mt/32850582/1643496 > Group Owner: devel+ow...@edk2.groups.io > Unsubscribe: https://edk2.groups.io/g/devel/unsub > [michael.d.kin...@intel.com] > -=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45743): https://edk2.groups.io/g/devel/message/45743 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Acked-by: Jiewen Yao Reviewed-by: Jiewen Yao From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io Sent: Thursday, August 15, 2019 10:22 AM To: Gao, Liming ; devel@edk2.groups.io; Yao, Jiewen ; Kinney, Michael D Cc: Laszlo Ersek ; leif.lindh...@linaro.org; af...@apple.com; Cetola, Stephano Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Liming, Thank you for adding everyone to the CC list. Yes, I would like this to be merged into the next EDK II stable release. Best regards, Vitaly On чт, авг. 15, 2019 at 04:59, Gao, Liming mailto:liming@intel.com>> wrote: Vitaly: As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose this patch plan to catch this stable tag? If yes, please ask the feedback from Tianocore Stewards. I have cc this patch to all Stewards. Thanks Liming From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Yao, Jiewen Sent: Thursday, August 15, 2019 9:05 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; vit9...@protonmail.com<mailto:vit9...@protonmail.com>; Kinney, Michael D mailto:michael.d.kin...@intel.com>> Cc: Laszlo Ersek mailto:ler...@redhat.com>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Good input. I think we should separate the work to convert all EDKII code to use STATIC_ASSERT. We can do that work once we add STATIC_ASSERT. I recommend: 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove VERIFY_SIZE_OF – the other patch and the other Bugzilla 3) Step 3: Scan the rest, if there is need. – Another patch and another Bugzilla Thank you Yao Jiewen From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io Sent: Thursday, August 15, 2019 12:23 AM To: Kinney, Michael D mailto:michael.d.kin...@intel.com>> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek mailto:ler...@redhat.com>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Michael, Liming, Laszlo, Static assertions via _Static_assert are standard C11 functionality, thus any at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the second argument with the diagnostic description. The notation without the message currently is only present in C++, not in C, thus the two-argument notation is the only allowed notation for _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. In the bottom of this message I included a quote from C17 for the relevant section (6.7.10). GCC and CLANG (including Xcode) appear to be conforming to the standard for this section, and MSVC compiler static_assert extension also supports the diagnostic message argument. This is pretty much all we care about. As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside of the standard reference in its description and actual usage in the source code, but can do that just fine if you think that it may help somebody. I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. This should be fairly costless, as apparently it is only used in Base.h and MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the same patch set. As for select ASSERT usage switching to STATIC_ASSERT, this would also be great, as let us be honest, the use of ASSERT in EDK II codebase is very questioning. In fact, this was one of the reasons we introduced our own static assertions some time ago. However, fixing up all broken assertions is unlikely a best place to fit into this patchset, but I can surely add a few examples, in case somebody points them out. This will be useful for reference purposes and may help the maintainers to get a better idea when static assertions are to be used. Looking forward to hearing your opinions. Best regards, Vitaly 6.7.10 Static assertions Syntax 1 static_assert-declaration: _Static_assert ( constant-expression , string-literal ) ; Constraints 2 The constant expression shall compare unequal to 0. Semantics 3 The constant expression shall be an integer constant expression. If the value of the constant expression compares unequal to 0, the declaration has no effect. Otherwise, the constraint is violated and the implementation shall produce a diagnostic message that includes the text of the string literal, except that characters not in the basic source character set are not required to appear in the message. Forward references: diagnostics (7.2). 7.2 Diagnostics 3 The macro static_assert expands to _Static_assert. > 14 авг. 2019 г., в 18:47, Kinney, Michael D > mailto:michael.d.kin...@
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Liming, Thank you for adding everyone to the CC list. Yes, I would like this to be merged into the next EDK II stable release. Best regards, Vitaly On чт, авг. 15, 2019 at 04:59, Gao, Liming wrote: > Vitaly: > > As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose > this patch plan to catch this stable tag? > > If yes, please ask the feedback from Tianocore Stewards. I have cc this > patch to all Stewards. > > Thanks > > Liming[] > > []From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, > Jiewen > Sent: Thursday, August 15, 2019 9:05 AM > To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D > > Cc: Laszlo Ersek > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro > > Good input. > > I think we should separate the work to convert all EDKII code to use > STATIC_ASSERT. > > We can do that work once we add STATIC_ASSERT. > > I recommend: > > 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla > > 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove > VERIFY_SIZE_OF – the other patch and the other Bugzilla > > 3) Step 3: Scan the rest, if there is need. – Another patch and another > Bugzilla > > Thank you > > Yao Jiewen > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly > Cheptosv via Groups.Io > Sent: Thursday, August 15, 2019 12:23 AM > To: Kinney, Michael D > Cc: devel@edk2.groups.io; Laszlo Ersek > Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro > > Michael, Liming, Laszlo, > > Static assertions via _Static_assert are standard C11 functionality, thus any > at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support > the second argument with the diagnostic description. > > The notation without the message currently is only present in C++, not in C, > thus the two-argument notation is the only allowed notation for > _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. > > In the bottom of this message I included a quote from C17 for the relevant > section (6.7.10). > > GCC and CLANG (including Xcode) appear to be conforming to the standard for > this section, and MSVC compiler static_assert extension also supports the > diagnostic message argument. This is pretty much all we care about. > > As for examples, I see little reason to clarify STATIC_ASSERT behaviour > outside of the standard reference in its description and actual usage in the > source code, but can do that just fine if you think that it may help somebody. > > I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, > and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. > This should be fairly costless, as apparently it is only used in Base.h and > MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in > the same patch set. > > As for select ASSERT usage switching to STATIC_ASSERT, this would also be > great, as let us be honest, the use of ASSERT in EDK II codebase is very > questioning. In fact, this was one of the reasons we introduced our own > static assertions some time ago. However, fixing up all broken assertions is > unlikely a best place to fit into this patchset, but I can surely add a few > examples, in case somebody points them out. This will be useful for reference > purposes and may help the maintainers to get a better idea when static > assertions are to be used. > > Looking forward to hearing your opinions. > > Best regards, > Vitaly > > 6.7.10 Static assertions > > Syntax > 1 static_assert-declaration: > _Static_assert ( constant-expression , string-literal ) ; > > Constraints > 2 The constant expression shall compare unequal to 0. > > Semantics > 3 The constant expression shall be an integer constant expression. If the > value of the constant expression compares unequal to 0, the declaration has > no effect. Otherwise, the constraint is violated and the implementation shall > produce a diagnostic message that includes the text of the string literal, > except that characters not in the basic source character set are not required > to appear in the message. > > Forward references: diagnostics (7.2). > > 7.2 Diagnostics > > 3 The macro > static_assert > expands to _Static_assert. > >> 14авг. 2019 г., в 18:47, Kinney, Michael D >> написал(а): >> >> >> Liming, >> >> I think a good candidate to demonstrate this >> feature are the checks made in MdePkg/Include/Base.h. >> The current implementation forces a divide by 0 >> i
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Vitaly: As you know, edk2 201908 stable tag will start soft freeze tomorrow. Dose this patch plan to catch this stable tag? If yes, please ask the feedback from Tianocore Stewards. I have cc this patch to all Stewards. Thanks Liming From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Yao, Jiewen Sent: Thursday, August 15, 2019 9:05 AM To: devel@edk2.groups.io; vit9...@protonmail.com; Kinney, Michael D Cc: Laszlo Ersek Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Good input. I think we should separate the work to convert all EDKII code to use STATIC_ASSERT. We can do that work once we add STATIC_ASSERT. I recommend: 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove VERIFY_SIZE_OF – the other patch and the other Bugzilla 3) Step 3: Scan the rest, if there is need. – Another patch and another Bugzilla Thank you Yao Jiewen From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io Sent: Thursday, August 15, 2019 12:23 AM To: Kinney, Michael D mailto:michael.d.kin...@intel.com>> Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek mailto:ler...@redhat.com>> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Michael, Liming, Laszlo, Static assertions via _Static_assert are standard C11 functionality, thus any at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the second argument with the diagnostic description. The notation without the message currently is only present in C++, not in C, thus the two-argument notation is the only allowed notation for _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. In the bottom of this message I included a quote from C17 for the relevant section (6.7.10). GCC and CLANG (including Xcode) appear to be conforming to the standard for this section, and MSVC compiler static_assert extension also supports the diagnostic message argument. This is pretty much all we care about. As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside of the standard reference in its description and actual usage in the source code, but can do that just fine if you think that it may help somebody. I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. This should be fairly costless, as apparently it is only used in Base.h and MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the same patch set. As for select ASSERT usage switching to STATIC_ASSERT, this would also be great, as let us be honest, the use of ASSERT in EDK II codebase is very questioning. In fact, this was one of the reasons we introduced our own static assertions some time ago. However, fixing up all broken assertions is unlikely a best place to fit into this patchset, but I can surely add a few examples, in case somebody points them out. This will be useful for reference purposes and may help the maintainers to get a better idea when static assertions are to be used. Looking forward to hearing your opinions. Best regards, Vitaly 6.7.10 Static assertions Syntax 1 static_assert-declaration: _Static_assert ( constant-expression , string-literal ) ; Constraints 2 The constant expression shall compare unequal to 0. Semantics 3 The constant expression shall be an integer constant expression. If the value of the constant expression compares unequal to 0, the declaration has no effect. Otherwise, the constraint is violated and the implementation shall produce a diagnostic message that includes the text of the string literal, except that characters not in the basic source character set are not required to appear in the message. Forward references: diagnostics (7.2). 7.2 Diagnostics 3 The macro static_assert expands to _Static_assert. > 14 авг. 2019 г., в 18:47, Kinney, Michael D > mailto:michael.d.kin...@intel.com>> написал(а): > > > Liming, > > I think a good candidate to demonstrate this > feature are the checks made in MdePkg/Include/Base.h. > The current implementation forces a divide by 0 > in the C pre-processor to break the build. > STATIC_ASSERT() would be a better way to do this. > I would also remove unused externs from the builds. > > /** > Verifies the storage size of a given data type. > > This macro generates a divide by zero error or a zero size array declaration > in > the preprocessor if the size is incorrect. These are declared as "extern" so > the space for these arrays will not be in the modules. > > @param TYPE The date type to determine the size of. > @param Size The expected size for the TYPE. > > **/ > #d
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Good input. I think we should separate the work to convert all EDKII code to use STATIC_ASSERT. We can do that work once we add STATIC_ASSERT. I recommend: 1) Step 1: Add STATIS_ASSERT - this patch and this Bugzilla 2) Step 2: Convert VERIFY_SIZE_OF to STATIS_ASSERT, and remove VERIFY_SIZE_OF – the other patch and the other Bugzilla 3) Step 3: Scan the rest, if there is need. – Another patch and another Bugzilla Thank you Yao Jiewen From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Vitaly Cheptosv via Groups.Io Sent: Thursday, August 15, 2019 12:23 AM To: Kinney, Michael D Cc: devel@edk2.groups.io; Laszlo Ersek Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro Michael, Liming, Laszlo, Static assertions via _Static_assert are standard C11 functionality, thus any at least C11 (ISO/IEC 9899 2011) conforming compiler is required to support the second argument with the diagnostic description. The notation without the message currently is only present in C++, not in C, thus the two-argument notation is the only allowed notation for _Static_assert for at least C17 (ISO/IEC 9899 2018) and below. In the bottom of this message I included a quote from C17 for the relevant section (6.7.10). GCC and CLANG (including Xcode) appear to be conforming to the standard for this section, and MSVC compiler static_assert extension also supports the diagnostic message argument. This is pretty much all we care about. As for examples, I see little reason to clarify STATIC_ASSERT behaviour outside of the standard reference in its description and actual usage in the source code, but can do that just fine if you think that it may help somebody. I fully agree that VERIFY_SIZE_OF usage should be converted to STATIC_ASSERT, and in fact I also suggest VERIFY_SIZE_OF to be entirely removed from Base.h. This should be fairly costless, as apparently it is only used in Base.h and MdeModulePkg/Library/ResetUtilityLib/ResetUtility.c, which I can replace in the same patch set. As for select ASSERT usage switching to STATIC_ASSERT, this would also be great, as let us be honest, the use of ASSERT in EDK II codebase is very questioning. In fact, this was one of the reasons we introduced our own static assertions some time ago. However, fixing up all broken assertions is unlikely a best place to fit into this patchset, but I can surely add a few examples, in case somebody points them out. This will be useful for reference purposes and may help the maintainers to get a better idea when static assertions are to be used. Looking forward to hearing your opinions. Best regards, Vitaly 6.7.10 Static assertions Syntax 1 static_assert-declaration: _Static_assert ( constant-expression , string-literal ) ; Constraints 2 The constant expression shall compare unequal to 0. Semantics 3 The constant expression shall be an integer constant expression. If the value of the constant expression compares unequal to 0, the declaration has no effect. Otherwise, the constraint is violated and the implementation shall produce a diagnostic message that includes the text of the string literal, except that characters not in the basic source character set are not required to appear in the message. Forward references: diagnostics (7.2). 7.2 Diagnostics 3 The macro static_assert expands to _Static_assert. > 14 авг. 2019 г., в 18:47, Kinney, Michael D > mailto:michael.d.kin...@intel.com>> написал(а): > > > Liming, > > I think a good candidate to demonstrate this > feature are the checks made in MdePkg/Include/Base.h. > The current implementation forces a divide by 0 > in the C pre-processor to break the build. > STATIC_ASSERT() would be a better way to do this. > I would also remove unused externs from the builds. > > /** > Verifies the storage size of a given data type. > > This macro generates a divide by zero error or a zero size array declaration > in > the preprocessor if the size is incorrect. These are declared as "extern" so > the space for these arrays will not be in the modules. > > @param TYPE The date type to determine the size of. > @param Size The expected size for the TYPE. > > **/ > #define VERIFY_SIZE_OF(TYPE, Size) extern UINT8 > _VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))] > > // > // Verify that ProcessorBind.h produced UEFI Data Types that are compliant > with > // Section 2.3.1 of the UEFI 2.3 Specification. > // > VERIFY_SIZE_OF (BOOLEAN, 1); > VERIFY_SIZE_OF (INT8, 1); > VERIFY_SIZE_OF (UINT8, 1); > VERIFY_SIZE_OF (INT16, 2); > VERIFY_SIZE_OF (UINT16, 2); > VERIFY_SIZE_OF (INT32, 4); > VERIFY_SIZE_OF (UINT32, 4); > VERIFY_SIZE_OF (INT64, 8); > VERIFY_SIZE_OF (UINT64, 8); > VERIFY_SIZE_OF (CHAR8, 1); > VERIFY_SIZE_OF (CHAR16, 2); > > // >
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
_SIZE, 4); > > A couple examples. Do all the compilers support the message parameter too? > > STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI > Specification Data Type requirements") > STATIC_ASSERT (sizeof (UINT16) == 2, "sizeof (UINT16) does not meet UEFI > Specification Data Type requirements") > STATIC_ASSERT (sizeof (INT32) == 4, "sizeof (INT32) does not meet UEFI > Specification Data Type requirements") > STATIC_ASSERT (sizeof (CHAR16) == 2, "sizeof (CHAR16) does not meet UEFI > Specification Data Type requirements") > STATIC_ASSERT (sizeof (__VERIFY_UINT8_ENUM_SIZE) == 4, "Size of enum does not > meet UEFI Specification Data Type requirements") > STATIC_ASSERT (sizeof (__VERIFY_UINT32_ENUM_SIZE) == 4, "Size of enum does > not meet UEFI Specification Data Type requirements") > > Thanks, > > Mike > >> -Original Message- >> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] >> On Behalf Of Liming Gao >> Sent: Wednesday, August 14, 2019 6:50 AM >> To: devel@edk2.groups.io; vit9...@protonmail.com >> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add >> STATIC_ASSERT macro >> >> Can you add the sample usage of new macro STATIC_ASSERT? >> >> Or, give the link of static_assert or _Static_assert. >> >> If so, the developer knows how to use them in source >> code. >> >> Thanks >> Liming >>> -Original Message- >>> From: devel@edk2.groups.io >> [mailto:devel@edk2.groups.io] On Behalf Of >>> vit9696 via Groups.Io >>> Sent: Tuesday, August 13, 2019 4:17 PM >>> To: devel@edk2.groups.io >>> Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add >> STATIC_ASSERT macro >>> >>> >> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 >>> >>> Provide a macro for compile time assertions. >>> Equivalent to C11 static_assert macro from assert.h. >>> >>> Signed-off-by: Vitaly Cheptsov >> >>> --- >>> MdePkg/Include/Base.h | 11 +++ >>> 1 file changed, 11 insertions(+) >>> >>> diff --git a/MdePkg/Include/Base.h >> b/MdePkg/Include/Base.h index >>> ce20b5f01dce..f85f7028a262 100644 >>> --- a/MdePkg/Include/Base.h >>> +++ b/MdePkg/Include/Base.h >>> @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST; >> #define >>> OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field)) >> #endif >>> >>> +/// >>> +/// Portable definition for compile time assertions. >>> +/// Equivalent to C11 static_assert macro from >> assert.h. >>> +/// Takes condtion and error message as its >> arguments. >>> +/// >>> +#ifdef _MSC_EXTENSIONS >>> + #define STATIC_ASSERT static_assert #else >>> + #define STATIC_ASSERT _Static_assert #endif >>> + >>> /** >>> Macro that returns a pointer to the data structure >> that contains a specified field of >>> that data structure. This is a lightweight method >> to hide >>> information by placing a >>> -- >>> 2.20.1 (Apple Git-117) >>> >>> >>> -=-=-=-=-=-= >>> Groups.io Links: You receive all messages sent to this >> group. >>> >>> View/Reply Online (#45503): >>> https://edk2.groups.io/g/devel/message/45503 >>> Mute This Topic: https://groups.io/mt/32850582/1759384 >>> Group Owner: devel+ow...@edk2.groups.io >>> Unsubscribe: https://edk2.groups.io/g/devel/unsub >>> [liming@intel.com] -=-=-=-=-=-= >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45622): https://edk2.groups.io/g/devel/message/45622 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=- signature.asc Description: OpenPGP digital signature
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Liming,
I think a good candidate to demonstrate this
feature are the checks made in MdePkg/Include/Base.h.
The current implementation forces a divide by 0
in the C pre-processor to break the build.
STATIC_ASSERT() would be a better way to do this.
I would also remove unused externs from the builds.
/**
Verifies the storage size of a given data type.
This macro generates a divide by zero error or a zero size array declaration
in
the preprocessor if the size is incorrect. These are declared as "extern" so
the space for these arrays will not be in the modules.
@param TYPE The date type to determine the size of.
@param Size The expected size for the TYPE.
**/
#define VERIFY_SIZE_OF(TYPE, Size) extern UINT8
_VerifySizeof##TYPE[(sizeof(TYPE) == (Size)) / (sizeof(TYPE) == (Size))]
//
// Verify that ProcessorBind.h produced UEFI Data Types that are compliant with
// Section 2.3.1 of the UEFI 2.3 Specification.
//
VERIFY_SIZE_OF (BOOLEAN, 1);
VERIFY_SIZE_OF (INT8, 1);
VERIFY_SIZE_OF (UINT8, 1);
VERIFY_SIZE_OF (INT16, 2);
VERIFY_SIZE_OF (UINT16, 2);
VERIFY_SIZE_OF (INT32, 4);
VERIFY_SIZE_OF (UINT32, 4);
VERIFY_SIZE_OF (INT64, 8);
VERIFY_SIZE_OF (UINT64, 8);
VERIFY_SIZE_OF (CHAR8, 1);
VERIFY_SIZE_OF (CHAR16, 2);
//
// The following three enum types are used to verify that the compiler
// configuration for enum types is compliant with Section 2.3.1 of the
// UEFI 2.3 Specification. These enum types and enum values are not
// intended to be used. A prefix of '__' is used avoid conflicts with
// other types.
//
typedef enum {
__VerifyUint8EnumValue = 0xff
} __VERIFY_UINT8_ENUM_SIZE;
typedef enum {
__VerifyUint16EnumValue = 0x
} __VERIFY_UINT16_ENUM_SIZE;
typedef enum {
__VerifyUint32EnumValue = 0x
} __VERIFY_UINT32_ENUM_SIZE;
VERIFY_SIZE_OF (__VERIFY_UINT8_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT16_ENUM_SIZE, 4);
VERIFY_SIZE_OF (__VERIFY_UINT32_ENUM_SIZE, 4);
A couple examples. Do all the compilers support the message parameter too?
STATIC_ASSERT (sizeof (BOOLEAN) == 1, "sizeof (BOOLEAN) does not meet UEFI
Specification Data Type requirements")
STATIC_ASSERT (sizeof (UINT16) == 2, "sizeof (UINT16) does not meet UEFI
Specification Data Type requirements")
STATIC_ASSERT (sizeof (INT32) == 4, "sizeof (INT32) does not meet UEFI
Specification Data Type requirements")
STATIC_ASSERT (sizeof (CHAR16) == 2, "sizeof (CHAR16) does not meet UEFI
Specification Data Type requirements")
STATIC_ASSERT (sizeof (__VERIFY_UINT8_ENUM_SIZE) == 4, "Size of enum does not
meet UEFI Specification Data Type requirements")
STATIC_ASSERT (sizeof (__VERIFY_UINT32_ENUM_SIZE) == 4, "Size of enum does not
meet UEFI Specification Data Type requirements")
Thanks,
Mike
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> On Behalf Of Liming Gao
> Sent: Wednesday, August 14, 2019 6:50 AM
> To: devel@edk2.groups.io; vit9...@protonmail.com
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
>
> Can you add the sample usage of new macro STATIC_ASSERT?
>
> Or, give the link of static_assert or _Static_assert.
>
> If so, the developer knows how to use them in source
> code.
>
> Thanks
> Liming
> > -Original Message-
> > From: devel@edk2.groups.io
> [mailto:devel@edk2.groups.io] On Behalf Of
> > vit9696 via Groups.Io
> > Sent: Tuesday, August 13, 2019 4:17 PM
> > To: devel@edk2.groups.io
> > Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
> >
> >
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048
> >
> > Provide a macro for compile time assertions.
> > Equivalent to C11 static_assert macro from assert.h.
> >
> > Signed-off-by: Vitaly Cheptsov
>
> > ---
> > MdePkg/Include/Base.h | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/MdePkg/Include/Base.h
> b/MdePkg/Include/Base.h index
> > ce20b5f01dce..f85f7028a262 100644
> > --- a/MdePkg/Include/Base.h
> > +++ b/MdePkg/Include/Base.h
> > @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST;
> #define
> > OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field))
> #endif
> >
> > +///
> > +/// Portable definition for compile time assertions.
> > +/// Equivalent to C11 static_assert macro from
> assert.h.
> > +/// Takes condtion and error message as its
> arguments.
> > +///
> > +#ifdef _MSC_EXTENSIONS
> > + #define STATIC_ASSERT static_assert #else
> > + #define STATIC_ASSERT _Static_assert #endif
> > +
> > /**
> >Macro that returns a pointer to the data structure
> that contains a specified field of
> >that data structure. This is a lightweight me
Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro
Can you add the sample usage of new macro STATIC_ASSERT? Or, give the link of static_assert or _Static_assert. If so, the developer knows how to use them in source code. Thanks Liming > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of vit9696 > via Groups.Io > Sent: Tuesday, August 13, 2019 4:17 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] [PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2048 > > Provide a macro for compile time assertions. > Equivalent to C11 static_assert macro from assert.h. > > Signed-off-by: Vitaly Cheptsov > --- > MdePkg/Include/Base.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/MdePkg/Include/Base.h b/MdePkg/Include/Base.h > index ce20b5f01dce..f85f7028a262 100644 > --- a/MdePkg/Include/Base.h > +++ b/MdePkg/Include/Base.h > @@ -843,6 +843,17 @@ typedef UINTN *BASE_LIST; > #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field)) > #endif > > +/// > +/// Portable definition for compile time assertions. > +/// Equivalent to C11 static_assert macro from assert.h. > +/// Takes condtion and error message as its arguments. > +/// > +#ifdef _MSC_EXTENSIONS > + #define STATIC_ASSERT static_assert > +#else > + #define STATIC_ASSERT _Static_assert > +#endif > + > /** >Macro that returns a pointer to the data structure that contains a > specified field of >that data structure. This is a lightweight method to hide information by > placing a > -- > 2.20.1 (Apple Git-117) > > > -=-=-=-=-=-= > Groups.io Links: You receive all messages sent to this group. > > View/Reply Online (#45503): https://edk2.groups.io/g/devel/message/45503 > Mute This Topic: https://groups.io/mt/32850582/1759384 > Group Owner: devel+ow...@edk2.groups.io > Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming@intel.com] > -=-=-=-=-=-= -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#45606): https://edk2.groups.io/g/devel/message/45606 Mute This Topic: https://groups.io/mt/32850582/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
