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>
Change BASE_NAME from "tftpDynamicCommand" to "TftpDynamicCommand"
to follow code style for names.
The use of 'T' in the directory name and INF file name and the
use of 't' in BASE_NAME causes build failures on Linux
platforms due to a mismatch in file/directory names in the
build output directory. Following the code style resolves this
issue.
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.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>
Make use the newly introduced ShellPrintHiiDefaultEx() alias and
replace wherever it is possible:
- "ShellPrintHiiEx (-1, -1, NULL,"
with:
- "ShellPrintHiiDefaultEx ("
No functional change is introduced.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.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>
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=1433
v2: Remove an unused variable.
Current logic of shell tftp download was writing file after tftp
download finished, when the file is large, it looks like the shell
tftp command hanged after download was finished. To improve
end-user experience, the solution is using split file writing
instead.
This patch update the code to open and close file inside
DownloadFile(), and save each packet to file within callback
function CheckPacket().
Since AllocatePage() is no-longer needed, This patch can also
remove the memory limitation. The download file can be larger
than system free memory now.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Songpeng Li <songpeng.li@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
[-c <retry count>] is to define the number of times to transmit request
packets and wait for a response. The default value is 6. But it doesn't
specify the behavior of zero value. Here, The patch is to clear that:
Set to zero also means to use the default value.
Cc: Carsey Jaben <jaben.carsey@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@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>
When dynamic command drivers are built into FV and start during
boot, they fails. Because Shell protocol doesn't exist during boot.
The patch sets Shell protocol and also set PcdShellLibAutoInitialize
to FALSE to ensure that
1. Shell protocol check doesn't happen in driver's entry point.
2. Driver can get the Shell protocol in DynamicCommand.Handler().
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
UEFI Shell spec defines Shell Dynamic Command protocol which is just
for the purpose to extend internal command.
So tftp command is changed from NULL class library to be a driver
producing DynamicCommand protocol.
The guideline is:
1. Only use NULL class library for Shell spec defined commands.
2. New commands can be provided as not only a standalone application
but also a dynamic command. So it can be used either as an
internal command, but also as a standalone application.
TftpApp.inf is to provide a standalone application.
TftpDynamicCommand.inf is to provide a standalone driver producing
Dynamic Command protocol.
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>
