Current code will allocate pool to hold the null char for name buffer
when PrevName==NULL, but the NameSize is still 0.
For this case, GetNextVariableName will return EFI_INVALID_PARAMETER
to follow UEFI 2.7 spec.
UEFI 2.7 spec:
The VariableNameSize must not be smaller the size of the variable
name string passed to GetNextVariableName() on input in the
VariableName buffer.
EFI_INVALID_PARAMETER
Null-terminator is not found in the first VariableNameSize bytes of
the input VariableName buffer.
This patch is to make NameSize to be consistent with name buffer.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The patch dumps memory map information for all memory types.
But to follow the SFO format of "memmap" defined in Shell 2.2 spec,
the patch doesn't dump the memory map information for OEM/OS
memory types. But it does include the OEM/OS memory in the total
size in SFO format.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The patch changes Buffer to Descriptors, changes
(UINT8 *Walker) to (EFI_MEMORY_DESCRIPTOR *Walker).
The change makes lots of type conversion unnecessary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The SMBIOS Type 0 BIOS segment field is currently displayed in decimal.
Since this field is likely to have a value like 0xE800 or 0xF000, using
hexadecimal seems like a better choice.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
It is to align to the original behavior before "-ec" option was
added.
The patch also refines the code to make it more readable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jim Dailey <Jim.Dailey@dell.com>
Shell 2.2 spec defines =0x/=0X, =H/=h, =S, =L and =P for
hex number, hex array, ascii string, unicode string and
device path data.
The patch adds such support.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
The patch doesn't impact the functionality.
The rename also fixes the inconsistency between function
header comments and function parameters.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
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: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@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: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Type 0: Update "EDD Enhanced Disk Driver)..." to
"EDD (Enhanced Disk Driver)..." for
STR_SMBIOSVIEW_PRINTINFO_EDD_ENHANCED_DRIVER
Type 3: Use L" Laptop" instead of L" LapTop" in
SystemEnclosureTypeTable to match SMBIOS spec.
Type 10: The BIT7 of Device Type is representing the
status of device whether it is enabled or disabled.
But current code is not considering the BIT7 and will
print "Undefined Value" for enabled device. Type 41
has same definition of Device Type, the code is
correct and will be applied to Type 10 by this patch.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@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>
Current PrintBitsInfo() will always print an additional trailing
" | " for the bit flags, for example,
Base Board Feature Flags: Hosting board | Replaceable |
Th patch is to eliminate trailing " | " in PrintBitsInfo(), then
the output will be like below
Base Board Feature Flags: Hosting board | Replaceable
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@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>
Song, BinX
HuajingLi
Star Zeng
Ruiyu Ni
Jeff Westfahl
Dandan Bi
Chen A Chen
Hao Wu