Replace traditional `#ifndef`/`#define`/`#endif` include guards with
`#pragma` once.
`#pragma once` is a widely supported preprocessor directive that
prevents header files from being included multiple times. It is
supported by all toolchains used to build edk2: GCC, Clang/LLVM, and
MSVC.
Compared to macro-based include guards, `#pragma once`:
- Eliminates the risk of macro name collisions or copy/paste errors
where two headers inadvertently use the same guard macro.
- Eliminate inconsistency in the way include guard macros are named
(e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.).
- Reduces boilerplate (three lines replaced by one).
- Avoids polluting the macro namespace with guard symbols.
- Can improve build times as the preprocessor can skip re-opening the
file entirely, rather than re-reading it to find the matching
`#endif` ("multiple-include optimization").
- Note that some compilers may already optimize traditional include
guards, by recognzining the idiomatic pattern.
This change is made acknowledging that overall portability of the
code will technically be reduced, as `#pragma once` is not part of the
C/C++ standards.
However, this is considered acceptable given:
1. edk2 already defines a subset of supported compilers in
BaseTools/Conf/tools_def.template, all of which have supported
`#pragma once` for over two decades.
2. There have been concerns raised to the project about inconsistent
include guard naming and potential macro collisions.
Approximate compiler support dates:
- MSVC: Supported since Visual C++ 4.2 (1996)
- GCC: Supported since 3.4 (2004)
(http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html)
- Clang (LLVM based): Since initial release in 2007
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Make use the newly introduced ShellPrintDefaultEx() alias and
replace wherever it is possible:
- "ShellPrintEx (-1, -1,"
with:
- "ShellPrintDefaultEx ("
No functional change is introduced.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Having StrLen(Buffer) == 0 results in a Buffer underflow.
Also, StrLen iterates over the Buffer elements until finding a NULL
character. This results in a quadratic search for '\r' characters
in the while loop.
Fix these issues.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
InternalShellIsHexOrDecimalNumber() would fail to interpret e.g. "0 " or
"00 " as valid numeric strings. After skipping the "0" digits as
leading zeroes, it would check if the next character is a valid hex or
decimal digit, which would then fail on the terminating character.
Therefore return success if "leading" zeroes have been consumed and
there are no more characters.
InternalShellStrHexToUint64() would fail to interpret e.g. "0 " or "00 "
as valid numeric strings. After skipping the "0" digits as leading
zeroes, it would find itself surprised by the following space.
Restrict the "bad space" check to the case where it had just consumed
the "x" or "X" marker. Otherwise the space is fine (depending on
StopAtSpace either end of number or interspersed space) since there
were only zeroes so far.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3080
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
The ShellConvertStringToUint64() function documentation says:
"Upon a successful return the value of the conversion."
So do not write any value if the conversion failed.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
StrSize() uses StrLen() which counts until the terminating NULL
character.
For checking for an empty string it is more efficient to directly check
for the NULL terminator instead of calling StrSize().
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
StrSize() will never return zero since it counts the terminating NULL
character.
An empty string will have the storage size of the terminator.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
If InternalShellStrHexToUint64() is passed a string that starts with 'X'
or 'x' it would try to read the byte before the start of the string
buffer.
Instead check if leading zeroes have been consumed.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Includes changes across the module for the following CodeQL rules:
- cpp/comparison-with-wider-type
- cpp/overflow-buffer
- cpp/redundant-null-check-param
- cpp/uselesstest
Co-authored-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Increase max buffer size to support more than 64K.
Signed-off-by: Giri Mudusuru <girim@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the ShellPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
edk2's UefiShellLib has no choice but to work around.
Improve the explanation in the code. Also, document the implicit
EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
dereferencing ParentHandle, with an explicit cast.
In practice, this patch is a no-op.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1906
While failed to allocate memory to save the response,
set the input/output parameter 'Response'(VOID **) to
NULL to indicate the failure not only depend on the
returned status.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Substitute InternalShellCharToUpper with CharToUpper which is a public
function with the same effect.
Remove the implement of InternalShellCharToUpper.
https://bugzilla.tianocore.org/show_bug.cgi?id=1369
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Add a function to return a clean, fully-qualified version of some path.
This function handles a (possibly "dirty") input path that may or may
not include a file system reference.
If it does not include a file system reference, then if the input path
does not begin with a forward or backward slash, then the input path is
relative to the current working directory of the current file system.
Otherwise, it is an absolute path within the current file system.
If it does include a file system reference, it may be a reference to the
current or some other file system. If the file system reference is not
immediately followed by a forward or backward slash, then the input path
is relative to the current working directory of the given file system.
Otherwise, it is an absolute path within the given file system.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey <jim_dailey@dell.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Replace the "old shell method" implementation in
ShellOpenFileByDevicePath() with EfiOpenFileByDevicePath() from UefiLib,
correcting the following issues:
- code duplication between this module and other modules,
- local variable name "EfiSimpleFileSystemProtocol" starting with "Efi"
prefix,
- bogus "FileHandle = NULL" assignments,
- leaking "Handle1" when the device path type/subtype check or the
realignment-motivated AllocateCopyPool() fails in the loop.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1008
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The ShellOpenFileByDevicePath() API promises to set the DeviceHandle
output parameter to the handle of the filesystem identified by the
FilePath input parameter. However, this doesn't actually happen when the
UEFI Shell 2.0 method is used (which is basically "always" nowadays).
Accordingly, the only caller of ShellOpenFileByDevicePath(), namely
ShellOpenFileByName(), defines a (dummy) local DeviceHandle variable just
so it can call ShellOpenFileByDevicePath().
Remove the useless output parameter.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1008
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
[Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.
Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.
Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.
Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@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>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
The previous change in ShellLib: "commit
3d29f8c5e3
* ShellPkg/ShellLib: Constructor doesn't depend on ShellParameters"
resolved the issue when loading dynamic command driver from Shell
environment.
But when dynamic command driver is built into FV and started during
boot, the driver still fails to start because Shell protocol doesn't
exist at that time.
The patch changes ShellLib to:
1. Do not look for Shell and ShellParameters protocol when they are
non-NULL in ShellLibConstructorWorker();
The two protocols are assumed to be set by DynamicCommand.Handler.
When ShellInitialize() is called in DynamicCommand.Handler, this
change can prevent the two protocols to be changed to NULL by
the locating logic.
2. Do not reset the Shell and ShellParameters protocol to NULL in
ShellLibDestructor() when CloseProtocol() fails;
Dynamic command driver needs to set the PcdShellLibAutoInitialize
to FALSE in order to skip the constructor.
Current logic calls ShellLibDestructor() when the PCD is FALSE when
ShellInitialize() is called. The change prevent the two protocols
to be changed to NULL.
The two changes don't impact existing usage case so they are backward
compatible.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
When ShellLib is linked to a driver producing DynamicCommand
protocol, ShellParameters protocol is set by
DynamicCommand.Handler().
The driver image handle doesn't have ShellParameters protocol
installed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
V2:
Fix MSFT C4255 warning
V1:
Enable MSFT C4255 warning.
From MSDN:
Compiler Warning (level 4) C4255
function' : no function prototype given: converting '()' to '(void)'
The compiler did not find an explicit list of arguments to a function.
This warning is for the C compiler only.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bell Song <binx.song@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Some developers/QAs complain the color of directory or executable
files is hard to see and suggest to use a more bright color.
I agree with this suggestion so make this patch.
The look and feel is much better now.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
MAX_FILE_NAME_LEN and FIND_XXXXX_FILE_BUFFER_SIZE are not used
by ShellLib so remove them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=566
In function InternalShellPrintWorker(), if the string in variable
'mPostReplaceFormat2' starts with character L'%', the following
expression:
*(ResumeLocation-1) == L'^' at line 2831
will read an undefined value before the starting of string
'mPostReplaceFormat2'.
This commit adds additional logic to avoid reading undefined content.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@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>
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>
