Module UNI and Package UNI files are not DOS format. Convert them to DOS format.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16042 6f19259b-4bc3-4df7-8a09-765794883524
2. Add MODULE_UNI_FILE file that contains the localized Abstract and Description of a module.
a. Addresses an information gap between INF files and the UEFI Distribution Packaging Specification XML schema
b. There will be an associated update to UPT in BaseTools to consume MODULE_UNI_FILE and associated UNI file during UDP creation that performs the INF -> XML conversion.
c. There will be an associated update to UPT in BaseTools to produce MODULE_UNI_FILE and associated UNI file during UDP installation that performs the XML -> INF conversion.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming <liming.gao@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15918 6f19259b-4bc3-4df7-8a09-765794883524
1. Usage information in INF file comment blocks are either incomplete or incorrect.
This includes usage information for Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.
The syntax for usage information in comment blocks is defined in the EDK II Module Information (INF) Specification
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gao, Liming <liming.gao@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15917 6f19259b-4bc3-4df7-8a09-765794883524
- 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
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
Gao, Liming
Eric Dong
Laszlo Ersek
lhauch