| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdePkg.
Visual Studio versions before VS 2015 don't support __func__ and so
will fail to compile. A workaround is to define __func__ as
__FUNCTION__ :
#define __func__ __FUNCTION__
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdePkg 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: Liming Gao <gaoliming@byosoft.com.cn>
|
|
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 <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
|
|
- The edk2 coding style prefers each variable declaration to stand on
its own line.
- Internal linkage (ie. STATIC) functions have caused problems with
source level debugging before, so we generally avoid STATIC in MdePkg.
- Even forward declarations of functions should carry full comment
blocks.
- Nullity checks in controlling expressions should be spelled out
explicitly, as (Ptr != NULL).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15843 6f19259b-4bc3-4df7-8a09-765794883524
|
|
VS2005 reports the following build failure:
BaseOrderedCollectionRedBlackTreeLib.c(151) : warning C4244:
'return' : conversion from 'int' to 'BOOLEAN', possible loss of data
BaseOrderedCollectionRedBlackTreeLib.c(840) : warning C4244:
'return' : conversion from 'int' to 'BOOLEAN', possible loss of data
This is incorrect. The ISO C standard guarantees that the expressions in
question can only return values 0 and 1, both of which can be represented
by BOOLEAN (== UINT8, == unsigned char).
Silence the incorrect warnings with explicit casts to BOOLEAN.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15813 6f19259b-4bc3-4df7-8a09-765794883524
|
|
Gcc-4.4 reports the following build failure:
BaseOrderedCollectionRedBlackTreeLib.c:
In function 'OrderedCollectionInsert':
BaseOrderedCollectionRedBlackTreeLib.c:586:
error: 'Result' may be used uninitialized in this function
This is incorrect. There are two areas of use of Result to consider:
- In the very first while loop. The warning is likely not about this code
area, because Result is assigned directly before use.
- The last use of Result in the function. The build warning / error is
incorrect. For Result to be uninitialized at that point, the very first
while loop must not have been entered at all (because that loop assigns
a value to Result). However, if that loop is never entered, then Parent
is still NULL. And Parent==NULL implies that the use of Result is never
reached, because we jump to the Done label just before it.
Assign an irrelevant value of 0 to Result at the beginning of the function
in order to silence the incorrect warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15812 6f19259b-4bc3-4df7-8a09-765794883524
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch <larry.hauch@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15807 6f19259b-4bc3-4df7-8a09-765794883524
|
|
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: lhauch <larry.hauch@intel.com>
Reviewed-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@hp.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15806 6f19259b-4bc3-4df7-8a09-765794883524
|
|
edk2 should have a fast and easy-to-use associative array (a dictionary)
type.
Red-black trees have O(log(n)) worst case time complexity for lookup,
insertion, and deletion (where n is the number of nodes in the tree). They
support minimum and maximum lookup with the same time complexity, hence
red-black trees double as priority queues as well.
Given an iterator to a red-black tree node, getting the next or previous
node (which corresponds to the ordered successor or the predecessor,
respectively, according to the user-defined ordering) is O(log(n)) as
well.
The code reflects the Binary Search Trees and Red-Black Trees chapters of
Introduction to Algorithms, by Cormen, Leiserson, Rivest. One point where
the implementation diverges is the first phase of the Delete() operation.
During that phase, the book's algorithm copies the key and other business
*contents* of the successor node (in case the successor node is affected),
and releases the successor node (instead of the node that the user
requested to delete).
While semantically correct, this would break the above iterator validity
guarantee. This implementation replaces the copying of business contents
between nodes with suitable relinking of nodes, so that all iterators
(except the one whose deletion is being requested) remain valid.
I had written this code originally in approx. 2002. I personally own the
copyright of that version and am hereby relicensing it to Red Hat, under
the BSDL. I had used the original code in a few personal projects since,
for example in the lbzip2-0.x parallel (de)compressor, and now I've ported
the library to edk2. Both during the original implementation and now
during the porting I verified all the cases and their proofs as rigorously
as I could, on paper. (NB, I couldn't find any errors in the 2002 code
now.)
During the porting to edk2, I documented all those cases in code comments
as well (at least half of the source is documentation). These comments are
not blind copies of diagrams from the Algorithms book, nor are they copies
from my original code -- I've done them all fresh now, and I've only
matched the results against the book. Reviewers are invited to sit down
with a pen, some paper, the book, and the code.
The Validate() function verifies the internal red-black properties of the
tree. This function helps with unit testing, and is only invoked when
requested with the PcdValidateOrderedCollection feature flag.
A note about diagrams: edges represented by backslash (\) characters are
often written as "\_", ie. with a following underscore. This is because
line-trailing backslashes are processed very early in compilation (in
translation phase 2), "splicing physical source lines to form logical
source lines". Since the edk2 coding style requires "//" comments for such
documentation, a trailing backslash would splice the next physical line
into the "scope" of the comment. To prevent this, trailing backslashes are
defanged by appending underscores, which should be visually bearable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15791 6f19259b-4bc3-4df7-8a09-765794883524
|
