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>
When copy command prompts to overwrite an existing file, pressing
backspace continuously removes everything including the shell prompt.
So print only valid characters for file overwrite prompt.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
In ShellOpenFileByName() the file is opened using
gEfiShellProtocol->OpenFileByName().
It is supposed that if this call returns an EFI_ERROR, the function
should return that error immediately. However, this return was missing,
and if UnicodeCollationProtocol has not been located by this time, the
Status gets overwritten with LocateProtocol() call result, which
eventually erroneously returns EFI_SUCCESS to the Shell.c, and this
leads to attempt to execute a non-existent startup script, which fails,
and which in turn leads to Shell being unloaded with "Invalid parameter"
error. This patch fixes the bug.
Cc: Tapan Shah <tapandshah@hpe.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Reviewed-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
As per ECR 1349 change in UEFI Shell Specification 2.2, expanding
a special output file name to include "NULL". Previously it only
supported "NUL" as a special output file and it was case sensitive.
With this change both "NUL" and "NULL" are special output file and
checked as case insensitive.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah <tapandshah@hpe.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
When ASSERT_EFI_ERROR() is compiled out, dependent on build flags, only
the status checking should be removed; the function calls should stay.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Shumin Qiu <shumin.qiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Do NULL pointer check before the pointer is used to avoid dereferenced.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
When the last line in a script file is not an empty line the Shell
will not execute the command in the last line. The patch refine the
logic in function 'ShellFileHandleReturnLine' and fix the issue.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
An earlier change had this function returning the type of lines that were in
the file being read (ASCII or UCS2). The way it is used, UCS2 output is
expected, even when the file being read is ASCII. This change restores that
behavior and documents it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <Jim_Dailey@Dell.com>
Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Fix various errors when piping a UNICODE or ASCII file to a simple shell application that reads standard input and writes it to standard output.
1) When the memory file is created by CreateFileInferfaceMem() to capture the pipe output, no UNICODE BOM is written to the memory file. Later, when the memory file is read by the application using ShellFileHandleReadLine(), the function indicates that the file is ASCII because there is no BOM.
2) If the file is piped as ASCII, the ASCII memory image is not correctly created by FileInterfaceMemWrite() as each ASCII character is followed by '\0' in the image (when the ASCII data is written to the memory image, the file position should only be incremented by half the buffer size).
3) ShellFileHandleReadLine() does not read ASCII files correctly (writes to Buffer need to be cast as CHAR8*).
4) FileInterfaceMemRead() and FileInterfaceMemWrite() as somewhat hard to read and difficult to debug with certain tools due to the typecasting of This. Added a local variable (MemFile) of the correct type to these functions and used it instead of This.
Enhancement: ShellFileHandleReadLine() now returns EFI_END_OF_FILE when appropriate.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Fix various errors when piping a UNICODE or ASCII file to a simple shell application that reads standard input and writes it to standard output.
1) When the memory file is created by CreateFileInferfaceMem() to capture the pipe output, no UNICODE BOM is written to the memory file. Later, when the memory file is read by the application using ShellFileHandleReadLine(), the function indicates that the file is ASCII because there is no BOM.
2) If the file is piped as ASCII, the ASCII memory image is not correctly created by FileInterfaceMemWrite() as each ASCII character is followed by '\0' in the image (when the ASCII data is written to the memory image, the file position should only be incremented by half the buffer size).
3) ShellFileHandleReadLine() does not read ASCII files correctly (writes to Buffer need to be cast as CHAR8*).
4) FileInterfaceMemRead() and FileInterfaceMemWrite() as somewhat hard to read and difficult to debug with certain tools due to the typecasting of This. Added a local variable (MemFile) of the correct type to these functions and used it instead of This.
Enhancement: ShellFileHandleReadLine() now returns EFI_END_OF_FILE when appropriate.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
In Shell spec 2.1 the return name of EFI_SHELL_PROTOCOL.GetCurDir() is defined as 'fs0:\current-dir' while in current implementation it's 'fs0:\current-dir\'.
To follow spec the patch removed the redundant '\' char.
Since it has been broken for a long time, some codes may depend on the broken behavior.
After this change 'EFI_SHELL_PROTOCOL.GetCurDir()' and 'UefiShellLib.ShellGetCurrentDir()'
will return a current directory string without tailing '\' (fs0:\current-dir), the value of Shell environment variable 'cwd' will become 'fs0:\current-dir' as well.
This patch has updated all the code in EDKII to make them depend on the new behavior.
Developers should check whether 'GetCurDir()' and 'ShellGetCurrentDir' are used in their source code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18653 6f19259b-4bc3-4df7-8a09-765794883524
also fixes a few out of date comments.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hp.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17816 6f19259b-4bc3-4df7-8a09-765794883524
In order to indicate the catena length use StrnCatS instead of StrCatS to generate Destination string, and update the DestMax of Destination string.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Tapan Shah <tapandshah@hp.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17795 6f19259b-4bc3-4df7-8a09-765794883524
ARM Compiler version 5 raises the warning/error (warning treated as error):
#191-D: type qualifier is meaningless on cast type
The compiler team said the warning is valid because from the C90 standard,
section 6.5.3 it is specified that "The properties associated with
qualified types are meaningful only for expressions that are lvalues."
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16888 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16601 ("MdeModulePkg, MdePkg, NetworkPkg, OvmfPkg, PerformancePkg,
ShellPkg: Library Migration.") incorporated ShellPkg/Library/BasePathLib
into MdePkg/Library/BaseLib. BasePathLib had been the only instance of
library class PathLib.
Even so, SVN r16606 ("ShellPkg: allow creating of files to create required
directory path") added a PathLib dependency to
"ShellPkg/Library/UefiShellLib/UefiShellLib.inf".
This breaks edk2 platforms that build the "new" UEFI shell from source.
Undo the wrong dependency.
Similarly, update the <Library/PathLib.h> #include directive to
<Library/BaseLib.h> (example function prototype: PathRemoveLastItem()).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16609 6f19259b-4bc3-4df7-8a09-765794883524
Shell Libraries can now be used from Platform Drivers with the
introduction of the Shell Dynamic Command Protocol.
Adding DXE_DRIVER class allows to use these libraries with this
class of driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Harry Liebel <Harry.Liebel@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <Jaben.Carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16052 6f19259b-4bc3-4df7-8a09-765794883524
This patch replaces StrCpy with StrnCpy or refactors out the usage of StrCpy through some other means.
This patch replaces StrCat with StrnCat or refactors out the usage of StrCat through some other means.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15839 6f19259b-4bc3-4df7-8a09-765794883524
This means we can use ShellExecute without thinking which shell
environment is in use. However it still isn't ideal: if
mEfiShellEnvironment2->Execute returns EFI_INVALID_PARAMETER, we can't tell
whether Execute() received an invalid parameter (e.g. ParentImageHandle was
NULL), or whether we tried to execute a command with an invalid parameter
(for example CommandLine "ls -hurdygurdy").
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brendan Jackman <Brendan.Jackman@arm.com>
Reviewed-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jaben Carsey <Jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15183 6f19259b-4bc3-4df7-8a09-765794883524
This change removes ASSERT statements and replaces them with logic to break out of the loop. This both prevents spinning forever and prevents processing the returned data from the function that failed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15133 6f19259b-4bc3-4df7-8a09-765794883524
This pointer never gets free when running new apps on the old shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15095 6f19259b-4bc3-4df7-8a09-765794883524
This allows for the user to get out of answering a question with CTRL-C
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14950 6f19259b-4bc3-4df7-8a09-765794883524
This function allows for easier access to printing standard command help.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Matt Stanbro <Matthew.A.Stanbro@intel.com>
Reviewed-by: Jaben Carsey <Jaben.carsey@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14159 6f19259b-4bc3-4df7-8a09-765794883524
Hao Wu
Tapan Shah
Ruiyu Ni
Chen A Chen
Vladimir Olovyannikov
Mudusuru, Giri P
Laszlo Ersek
Liming Gao
Qiu Shumin
Jim Dailey
Jaben Carsey
Yao Jiewen
Bruce Cran
Olivier Martin
jcarsey
Harry Liebel
Brendan Jackman
jcarsey