The following VFR statement was causing the VfrCompile to crash:
efivarstore UINT8,
attribute = 0,
name = STRING_TOKEN(STR_TEST3),
varsize = 1,
guid = { 0xf648132a, 0x4193, 0x4c13, { 0x85, 0x71, 0x33, 0xf0, 0x6d,
0x53, 0x74, 0xa9 } };
In the vfrStatementVarStor
I was hoping to receive some clarification about the VfrCompile's support of
defaults for the OrderedList vfr statement. OrderedLists support the
vfrStatementDefault grammer, but the vfrStatementDefault, through the
vfrConstantValueField, only seems to support a
Number/True/False/Time/Date/STR
Revision 2594 of the VfrUtilityLib.cpp removed the reporting of an error when
multiple questions define a default value for the same offset/Width/Value in a
Buffer varstore. (CVfrBufferConfig::Write used to return
VFR_RETURN_DEFAULT_VALUE_REDEFINED for this)
The changes associated with those ch
Attached is another patch for the VfrCompiler's string to integer functions
(STOU8, STOU16, STOU32, STOU64). The functions were not detecting when
overflow occurred while converting a string to an integer value. (i.e. when
"256" was being converted into a UINT8, it would be allowed and would re
I've attached a patch file to address an issue with the VfrCompiler's treatment
of the display flags for VFR numeric statements. Prior to this patch, the
vfrcompiler would never allow the IFR output to contain the flag to cause a
numeric to be displayed as a signed integer.
The CIfrNumeric clas
