Topics

[PATCH v2 1/1] MdePkg: Add STATIC_ASSERT macro


Vitaly Cheptsov
 

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D2048

Provide a macro for compile time assertions.
Equivalent to C11 static_assert macro from assert.h.

Signed-off-by: Vitaly Cheptsov <vit9696@...>
---
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
=20
+///
+/// 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 speci=
fied field of
that data structure. This is a lightweight method to hide information b=
y placing a
--=20
2.20.1 (Apple Git-117)


Liming Gao
 

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 <vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [liming.gao@...]
-=-=-=-=-=-=


Michael D Kinney
 

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 = 0xffff
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
__VerifyUint32EnumValue = 0xffffffff
} __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; vit9696@...
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
<vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[liming.gao@...] -=-=-=-=-=-=


Vitaly Cheptsov
 

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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.

14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):


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 = 0xffff
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
__VerifyUint32EnumValue = 0xffffffff
} __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; vit9696@...
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
<vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[liming.gao@...] -=-=-=-=-=-=


Yao, Jiewen
 

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 <michael.d.kinney@...>
Cc: devel@edk2.groups.io; Laszlo Ersek <lersek@...>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.

 

> 14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):
>
>
> 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 = 0xffff
> } __VERIFY_UINT16_ENUM_SIZE;
>
> typedef enum {
>  __VerifyUint32EnumValue = 0xffffffff
> } __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; vit9696@...
>> 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
>> <vit9696@...>
>>> ---
>>> 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+owner@edk2.groups.io
>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>> [liming.gao@...] -=-=-=-=-=-=
>>
>>
>>
>

 

 


Liming Gao
 

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; vit9696@...; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>
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 <michael.d.kinney@...>
Cc: devel@edk2.groups.io; Laszlo Ersek <lersek@...>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.

 

> 14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):
>
>
> 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 = 0xffff
> } __VERIFY_UINT16_ENUM_SIZE;
>
> typedef enum {
>  __VerifyUint32EnumValue = 0xffffffff
> } __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; vit9696@...
>> 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
>> <vit9696@...>
>>> ---
>>> 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+owner@edk2.groups.io
>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>> [liming.gao@...] -=-=-=-=-=-=
>>
>>
>>
>

 

 

 


Vitaly Cheptsov
 

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 <liming.gao@...> 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; vit9696@...; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>
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 <michael.d.kinney@...>
Cc: devel@edk2.groups.io; Laszlo Ersek <lersek@...>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.

 

> 14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):
>
>
> 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 = 0xffff
> } __VERIFY_UINT16_ENUM_SIZE;
>
> typedef enum {
>  __VerifyUint32EnumValue = 0xffffffff
> } __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; vit9696@...
>> 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
>> <vit9696@...>
>>> ---
>>> 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+owner@edk2.groups.io
>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>> [liming.gao@...] -=-=-=-=-=-=
>>
>>
>>
>

 

 

 




Yao, Jiewen
 

Acked-by: Jiewen Yao <Jiewen.yao@...>

Reviewed-by: Jiewen Yao <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 <liming.gao@...>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@...>; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>; leif.lindholm@...; afish@...; Cetola, Stephano <stephano.cetola@...>
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 <liming.gao@...> 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; vit9696@...; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>
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 <michael.d.kinney@...>
Cc: devel@edk2.groups.io; Laszlo Ersek <lersek@...>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.

 

> 14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):
>
>
> 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 = 0xffff
> } __VERIFY_UINT16_ENUM_SIZE;
>
> typedef enum {
>  __VerifyUint32EnumValue = 0xffffffff
> } __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; vit9696@...
>> 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
>> <vit9696@...>
>>> ---
>>> 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+owner@edk2.groups.io
>>> Unsubscribe: https://edk2.groups.io/g/devel/unsub
>>> [liming.gao@...] -=-=-=-=-=-=
>>
>>
>>
>

 

 

 

 

 


Michael D Kinney
 

Reviewed-by: Michael D Kinney <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 <vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[michael.d.kinney@...]
-=-=-=-=-=-=


Laszlo Ersek
 

On 08/14/19 18:22, vit9696@... wrote:
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.
Edk2 targets C95, to my understanding. If features from more recent C
language standards happen to work on all toolchains that edk2 supports,
then I agree we can put those language features to use -- but we should
document them, in the appropriate header file. In my opinion.


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.
I disagree with introducing a new macro to a core header file without
putting it to use at once, in at least one very commonly built
translation unit in edk2 itself. I would suggest to single out a few
core uses of ASSERT (e.g. in MdePkg or MdeModulePkg), and to convert them.

If you can replace VERIFY_SIZE_OF with STATIC_ASSERT, that could be a
perfect first use. Of course I'd suggest that the patches be separate --
first, add the new macro, second, gradually convert VERIFY_SIZE_OF. So
this intro work should be done as a small series.

I think that can belong to a single BZ.

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.
Wider ASSERT evaluation and conversion to STATIC_ASSERT should be done
later (separate BZs) if we ever have capacity for that.

Thanks
Laszlo



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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.


14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...> написал(а):


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 = 0xffff
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
__VerifyUint32EnumValue = 0xffffffff
} __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; vit9696@...
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
<vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[liming.gao@...] -=-=-=-=-=-=


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; vit9696@...; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>
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 <michael.d.kinney@...<mailto:michael.d.kinney@...>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek <lersek@...<mailto:lersek@...>>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.


14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>> написал(а):


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 = 0xffff
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
__VerifyUint32EnumValue = 0xffffffff
} __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> [mailto:devel@edk2.groups.io]
On Behalf Of Liming Gao
Sent: Wednesday, August 14, 2019 6:50 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; vit9696@...<mailto:vit9696@...>
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>
[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<mailto: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
<vit9696@...<mailto:vit9696@...>>
---
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+owner@edk2.groups.io<mailto:devel+owner@edk2.groups.io>
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[liming.gao@...] -=-=-=-=-=-=






Vitaly Cheptsov
 

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 <lersek@...> написал(а):


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; vit9696@...; Kinney, Michael D <michael.d.kinney@...>
Cc: Laszlo Ersek <lersek@...>
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 <michael.d.kinney@...<mailto:michael.d.kinney@...>>
Cc: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Laszlo Ersek <lersek@...<mailto:lersek@...>>
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 <assert. h>

3 The macro
static_assert
expands to _Static_assert.


14 авг. 2019 г., в 18:47, Kinney, Michael D <michael.d.kinney@...<mailto:michael.d.kinney@...>> написал(а):


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 = 0xffff
} __VERIFY_UINT16_ENUM_SIZE;

typedef enum {
__VerifyUint32EnumValue = 0xffffffff
} __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> [mailto:devel@edk2.groups.io]
On Behalf Of Liming Gao
Sent: Wednesday, August 14, 2019 6:50 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; vit9696@...<mailto:vit9696@...>
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>
[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<mailto: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
<vit9696@...<mailto:vit9696@...>>
---
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+owner@edk2.groups.io<mailto:devel+owner@edk2.groups.io>
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[liming.gao@...] -=-=-=-=-=-=






Laszlo Ersek
 

On 08/16/19 19:23, vit9696@... 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


Laszlo Ersek
 

On 08/15/19 18:08, Michael D Kinney wrote:
Reviewed-by: Michael D Kinney <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 <vit9696@...>
---
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+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[michael.d.kinney@...]
-=-=-=-=-=-=



Laszlo Ersek
 

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


Michael D Kinney
 

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: vit9696@...
Cc: devel@edk2.groups.io; leif.lindholm@...;
afish@...
Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
STATIC_ASSERT macro

On 08/16/19 19:23, vit9696@... 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


Vitaly Cheptsov
 

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 <lersek@...> wrote:
On 08/16/19 19:23, vit9696@... 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



Vitaly Cheptsov
 

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 <michael.d.kinney@...> 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: vit9696@...
> Cc: devel@edk2.groups.io; leif.lindholm@...;
> afish@...
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
>
> On 08/16/19 19:23, vit9696@... 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
>
>




rebecca@...
 

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


Andrew Fish
 



On Aug 16, 2019, at 2:40 PM, Vitaly Cheptsov via Groups.Io <vit9696@...> 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 <michael.d.kinney@...> 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: vit9696@...
> Cc: devel@edk2.groups.io; leif.lindholm@...;
> afish@...
> Subject: Re: [edk2-devel] [PATCH v2 1/1] MdePkg: Add
> STATIC_ASSERT macro
>
> On 08/16/19 19:23, vit9696@... 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
>
>