The EDK II C Coding Standards Specification (v2.20) strongly discourages
variable declarations in nested block scope:
5 Source Files
5.4 Code File Structure
5.4.1 Scoping Rules
5.4.1.1 Scope
> Block (local) Scope
>
> [...]
>
> Data declarations may follow the opening brace of a compound statement,
> regardless of nesting depth, and before any code generating statements
> have been entered. Other than at the outermost block of a function body,
> this type of declaration is strongly discouraged.
Hoist such variable declarations in Base64Decode() to the outermost
function scope.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Fixes: 35e242b698
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1980
Reported-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
Rewrite Base64Decode() from scratch, due to reasons listed in the second
reference below.
Implement Base64Decode() according to the specification added in the
previous patch. The decoder scans the input buffer once, it has no inner
loop(s), and it spills each output byte as soon as the output byte is
complete.
The intent is to only strengthen the checks (sanity and input) relative to
the previous implementation, hence the MAX_ADDRESS checks are reinstated.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1891
Ref: http://mid.mail-archive.com/c495bd0b-ea4d-7206-8a4f-a7149760d19a@redhat.com
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Tested-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
[lersek@redhat.com: add last para to commit msg per talks w/ Marvin & Phil]
Rewrite Base64Decode() from scratch, due to reasons listed in the second
reference below.
As first step, redo the interface contract, and replace the current
implementation with a stub that asserts FALSE, then fails.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Marvin Häuser <mhaeuser@outlook.de>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1891
Ref: http://mid.mail-archive.com/c495bd0b-ea4d-7206-8a4f-a7149760d19a@redhat.com
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Change the type of variable Chr from CHAR8 to UINT32 in a
bitwise operation, to make the two variables in the operation
have the same size.
https://bugzilla.tianocore.org/show_bug.cgi?id=1527
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Introduce public functions Base64Encode and Base64Decode.
https://bugzilla.tianocore.org/show_bug.cgi?id=1370
v2:1.Remove some white space.
2.Add unit test with test vectors in RFC 4648.
https://github.com/shenglei10/edk2/tree/encode_testhttps://github.com/shenglei10/edk2/tree/decode_test
v3:1.Align white space.
2.Update comments of Base64Encode and Base64Decode.
3.Change the use of macro RETURN_DEVICE_ERROR to
RETURN_INVALID_PARAMETER in string.c.
v4:Change parameters' names.
v5:1.Update usage of variables.
2.Remove debug message in Base64Decode().
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Introduce two public functions CharToUpper and AsciiCharToUpper.
They have the same functions as InternalCharToUpper and
InternalBaseLibAsciiToUpper.Considering the internal functions will
be removed,so directly I change their function names to the public ones'.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1262
Current implementation of BaseLib APIs:
AsciiStrToUnicodeStr()
AsciiStrToUnicodeStrS()
AsciiStrnToUnicodeStrS()
do not handle EASCII properly.
More specifically, if the value of ASCII character is larger than 0x7F,
then the converted Unicode character will have all '1's in the higher 8
bits.
An example:
0xC9 => 0xFFC9 (current implementations)
and it should be:
0xC9 => 0x00C9
This commit will address this issue.
Cc: Bin.Lain <bin_601@mail2000.com.tw>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This commit adds an addtional check in AsciiStriCmp. It
explicitly checks the end of the sting pointed by 'SecondString' to make
the code logic easier for reading and to prevent possible mis-reports by
static code checkers.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <Hao.a.wu@intel.com>
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@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: Laszlo Ersek <lersek@redhat.com>
For the following 8 APIs in MdePkg/BaseLib:
[Ascii]StrDecimalToUintn
[Ascii]StrDecimalToUint64
[Ascii]StrHexToUintn
[Ascii]StrHexToUint64
They will ASSERT for DEBUG build when the input string exceeds the range
of UINTN/UINT64. However, for RELEASE build, incorrect value will be
returned.
This commit refines those APIs to direcly call their enhanced counterparts
(with trailing 'S' in API names) so as to remove those exceed-range ASSERT
checks and to make those APIs to return MAX_UINTN/MAX_UINT64 instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This commit adds an addtional check in AsciiStrnCmp and StrnCmp. It
explicitly checks the end of the sting pointed by 'SecondString' to make
the code logic easier for reading and to prevent possible mis-reports by
static code checkers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Correct the typos in some files of MdePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
The overlap may happen when the address of Destination in
UnicodeStrToAsciiStr() or Source in AsciiStrToUnicodeStr()
is not two bytes aligned.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15665 6f19259b-4bc3-4df7-8a09-765794883524
Move IsHexDigit, BufToHexString, HexStringToBuf from BaseLib to MdeModulePkg IfrSupportLib. The reason is:
1) IsHexDigit function provides the logic to check Hex Digit and convert it to Decimal value, which is required by IScsi LUN and HII user input. But this logic is not provided by any functions in MdeLib. So, it can't be deleted. It is moved to IfrSupportLib.
2) BufToHexString function converts a array of buffers to hex string. If the buffer length is less than sizeof (UINT64), it can be directly replaced by UnicodeValueToString(). But HII modules may use BufToHexString to convert the buffers whose length > sizeof (UINT64). For example:
.\MdeModulePkg\Universal\HiiDatabaseDxe\ConfigRouting.c line 201, 1148
.\Universal\SetupBrowserDxe\Setup.c line line 1457, 1503
Like this case, it is not easy to use UnicodeValueToString to replace BufToHexString. So, BufToHexString is still kept. Because such usages are in HII modules, this function is moved to IfrSupportLib.
3) HexStringToBuf is moved to IfrSupportLib. The reason is similar to BufToHexString.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@6782 6f19259b-4bc3-4df7-8a09-765794883524
2. Clean BasePeCoff library instance, only keep one copy PeCoffLoaderEx.c file for IA32, X64 and IPF arch
3. Clean the confused comments
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5927 6f19259b-4bc3-4df7-8a09-765794883524
2. Adjust the return value of UnicodeStrToAsciiStr() & AsciiStrToUnicodeStr () to be the original destination string to follow MdeLib spec.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@4653 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek
Michael D Kinney
Shenglei Zhang
Mike Turner
Hao Wu
Ruiyu Ni
Liming Gao
Thomas Huth
Star Zeng
Eric Dong
jcarsey
sfu5
hhuan13
myronporter
hhtian
qhuang8
lgao4
rsun3
eric_tian
gikidy
qwang12
xli24
vanjeff
yshang1
klu2
AJFISH