Tianocore/edk2.git/MdePkg/Include/Pi/PiFirmwareFile.h, branch master

MdePkg/Include/Uefi: Add back include guard

2026-02-27T07:15:11+00:00

Add include guards back to include files that use the same include guard macro in BaseTools/Source/C/Include/Common and MdePkg or MdeModulePkg. Signed-off-by: Michael D Kinney

MdePkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

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

MdePkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdePkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Liming Gao

MdePkg/PiFirmwareFile: fix undefined behavior in FFS_FILE_SIZE

2019-04-24T15:31:00+00:00

Accessing "EFI_FFS_FILE_HEADER.Size", which is of type UINT8[3], through a (UINT32*), is undefined behavior. Fix it by accessing the array elements individually. Cc: Liming Gao Cc: Michael D Kinney Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Signed-off-by: Laszlo Ersek Reviewed-by: Philippe Mathieu-Daude Reviewed-by: Michael D Kinney Reviewed-by: Jordan Justen

MdePkg/PiFirmwareFile: fix undefined behavior in SECTION_SIZE

2019-04-24T15:30:54+00:00

RH covscan justifiedly reports that accessing "EFI_COMMON_SECTION_HEADER.Size", which is of type UINT8[3], through a (UINT32*), is undefined behavior: > Error: OVERRUN (CWE-119): > edk2-89910a39dcfd/OvmfPkg/Sec/SecMain.c:178: overrun-local: Overrunning > array of 3 bytes at byte offset 3 by dereferencing pointer > "(UINT32 *)((EFI_COMMON_SECTION_HEADER *)(UINTN)Section)->Size". > # 176| Section = (EFI_COMMON_SECTION_HEADER*)(UINTN) CurrentAddress; > # 177| > # 178|-> Size = SECTION_SIZE (Section); > # 179| if (Size < sizeof (*Section)) { > # 180| return EFI_VOLUME_CORRUPTED; Fix this by accessing the array elements individually. Cc: Liming Gao Cc: Michael D Kinney Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Issue: scan-1007.txt Signed-off-by: Laszlo Ersek Reviewed-by: Philippe Mathieu-Daude Reviewed-by: Michael D Kinney Reviewed-by: Jordan Justen

MdePkg/PiFirmwareFile: express IS_SECTION2 in terms of SECTION_SIZE

2019-04-24T15:30:46+00:00

The IS_SECTION2() function-like macro duplicates the SECTION_SIZE() calculation, just to compare the computed size against 0xFFFFFF. Invoke SECTION_SIZE() instead; only preserve the comparison. Cc: Liming Gao Cc: Michael D Kinney Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710 Signed-off-by: Laszlo Ersek Acked-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Michael D Kinney Reviewed-by: Jordan Justen

MdePkg: Replace BSD License with BSD+Patent License

2019-04-09T17:58:13+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Liming Gao

MdePkg/Include: Add management mode FV file type and depex.

2018-02-09T06:41:03+00:00

As per PI specification v1.6, As per section 2.1.4.1, The following file types exist: Table 3. Defined File Types Name Value EFI_FV_FILETYPE_RAW 0x01 EFI_FV_FILETYPE_FREEFORM 0x02 EFI_FV_FILETYPE_SECURITY_CORE 0x03 EFI_FV_FILETYPE_PEI_CORE 0x04 EFI_FV_FILETYPE_DXE_CORE 0x05 EFI_FV_FILETYPE_PEIM 0x06 EFI_FV_FILETYPE_DRIVER 0x07 EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 0x08 EFI_FV_FILETYPE_APPLICATION 0x09 EFI_FV_FILETYPE_MM 0x0A EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x0B EFI_FV_FILETYPE_COMBINED_MM_DXE 0x0C EFI_FV_FILETYPE_MM_CORE 0x0D EFI_FV_FILETYPE_MM_STANDALONE 0x0E EFI_FV_FILETYPE_MM_CORE_STANDALONE 0x0F The following new section type is added: EFI_SECTION_MM_DEPEX This patch adds the management mode FV file type and depex. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Achin Gupta Signed-off-by: Supreeth Venkatesh Reviewed-by: Jiewen Yao Reviewed-by: Liming Gao

MdePkg PiFirmwareFile.h: Add FFS_ATTRIB_DATA_ALIGNMENT_2 definition

2017-09-26T10:00:59+00:00

Follow PI 1.6 spec to add FFS_ATTRIB_DATA_ALIGNMENT_2 definition for FFS alignment extended to support maximum 16MB. Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng Reviewed-by: Liming Gao

MdePkg: Follow PI spec to update ExtendedSize in EFI_FFS_FILE_HEADER2

2015-08-24T01:43:20+00:00

for FFS data above 16 bytes alignment requirement. PI spec requires FFS header to be at 8 bytes alignment to FV header. And, FFS data alignment requires the beginning of the file data must be aligned on a particular boundary, such as 1, 16, 128 bytes or above. If FFS data alignment requires to be above 16 bytes, and FFS header must be at 8 byte alignment, so FFS header size must be multiple of 8. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18263 6f19259b-4bc3-4df7-8a09-765794883524