There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
For pointer subtraction, the result is of type "ptrdiff_t". According to
the C11 standard (Committee Draft - April 12, 2011):
"When two pointers are subtracted, both shall point to elements of the
same array object, or one past the last element of the array object; the
result is the difference of the subscripts of the two array elements. The
size of the result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header. If the result
is not representable in an object of that type, the behavior is
undefined."
In our codes, there are cases that the pointer subtraction is not
performed by pointers to elements of the same array object. This might
lead to potential issues, since the behavior is undefined according to C11
standard.
Also, since the size of type "ptrdiff_t" is implementation-defined. Some
static code checkers may warn that the pointer subtraction might underflow
first and then being cast to a bigger size. For example:
UINT8 *Ptr1, *Ptr2;
UINTN PtrDiff;
...
PtrDiff = (UINTN) (Ptr1 - Ptr2);
The commit will refine the pointer subtraction expressions by casting each
pointer to UINTN first and then perform the subtraction:
PtrDiff = (UINTN) Ptr1 - (UINTN) Ptr2;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
It is the follow up of 3ab41b7a32
to replace UnicodeStrToAsciiStr/AsciiStrToUnicodeStr with
UnicodeStrToAsciiStrS/AsciiStrToUnicodeStrS.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The recent patch titled
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call
has exposed a preexistent bug in the BdsLibBootViaBootOption() function,
and now the IA32 build of OVMF fails with:
In function 'BdsLibBootViaBootOption':
error: 'Status' may be used uninitialized in this function
Namely, we have the following (simplified) data flow:
//
// Status and ImageHandle both start out uninitialized
//
/* ... */
ImageHandle = BdsExpandUsbShortFormDevicePath (DevicePath);
/* ... */
if (ImageHandle == NULL) {
/* ... */
}
if ((ImageHandle == NULL) || (EFI_ERROR(Status))) {
/* ... */
*/
If BdsExpandUsbShortFormDevicePath() returns a non-NULL value, then the
second "if" statement will check Status without the function having
initialized or assigned it.
When BdsExpandUsbShortFormDevicePath() returns non-NULL, Status should be
EFI_SUCCESS; so let us assign it that value up-front.
Note that the bug existed before the patch
IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call
That is, the bug was not introduced, only exposed, by the patch -- in the
pre-patch state, although the Status variable was set early and
unconditionally, the error code that it may have carried from the failed
gEfiAcpiS3SaveProtocolGuid lookup had nothing to do with the second "if"
statement above.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18061 6f19259b-4bc3-4df7-8a09-765794883524
The AcpiS3->S3Save() call needs to occur before the end-of-DXE event
is signalled. The end-of-DXE event needs to be signalled prior to
invoking any UEFI drivers, applications, or connecting consoles.
This means the call to S3Save() that occurs in BdsLibBootViaBootOption()
violates the ordering constraints, and should be removed. Since it is
the responsibility of the platform BDS to signal the end-of-DXE event,
it should also perform the AcpiS3->S3Save() call at an appropriate time.
Commit message update from Laszlo Ersek <lersek@redhat.com>:
Following Jiewen Yao's idea in
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146
platforms that
(1) use this exact instance of GenericBdsLib, *and*
(2) support S3
should now collect the S3 state
(3) in an End-of-Dxe callback in their AcpiS3SaveDxe drivers, *or*
(4) with an explicit AcpiS3->S3Save() call made to their AcpiS3SaveDxe
drivers from their PlatformBdsLib instances.
OvmfPkg, which uses this GenericBdsLib instance, and has its own
AcpiS3SaveDxe fork, follows (3).
Vlv2TbltDevicePkg, which has a GenericBdsLib fork, and uses
IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe, follows (4).
There are no other platforms in the public edk2 repository that support
S3.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.Yao@intel.com>
[lersek@redhat.com: updated commit message]
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiewen Yao <Jiewen.Yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18036 6f19259b-4bc3-4df7-8a09-765794883524
For PI spec vol3,
"EFI_SW_DXE_BS_PC_LEGACY_BOOT_EVENT The event with GUID EFI_EVENT_LEGACY_BOOT_GUID was signaled."
"EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT The EFI_EVENT_GROUP_READY_TO_BOOT event was signaled."
However, in current code base, they are reported before events were signaled.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Elvin Li <elvin.li@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17124 6f19259b-4bc3-4df7-8a09-765794883524
0. Remove the unused private GUID from module source files.
1. Use gEfiCallerIdGuid replace of the private module GUID.
2. Add the public header files to define HII FormSet and PackageList GUID used in every HII driver.
3. Publish EFI_LEGACY_DEV_ORDER_VARIABLE_GUID from BdsDxe driver and EFI_UPDATE_DATA_FILE_GUID from UpdateDriverDxe to IntelFrameworkModulePkg Include directory.
Signed-off-by: lgao4
Reviewed-by: ydong10 gdong1 tye jfan12 wli12 rsun3 jyao1 ftian
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@12374 6f19259b-4bc3-4df7-8a09-765794883524
2.Add MSG_IPv4_DP and MSG_IPv6_DP into boot type of BDS_EFI_MESSAGE_MAC_BOOT.
3.Change the file header format of inf file and remove the MNP dependency.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9799 6f19259b-4bc3-4df7-8a09-765794883524
Hao Wu
Star Zeng
Laszlo Ersek
Ard Biesheuvel
Elvin Li
Ruiyu Ni
Jeff Fan
Chen Fan
Eric Dong
czhang46
lzeng14
li-elvin
niruiyu
ydong10
czhang46
lgao4
xdu2
qianouyang
hhtian
gikidy
tye1
xli24