On 2/2/2018 12:23 AM, Laszlo Ersek wrote:
On 02/01/18 10:47, krishnaLee wrote:
Hi,
For example,the follow code:
//-code-start
ConfigRequestHdr = HiiConstructConfigHdr (&mBlankDrvFormSetGuid, VariableName,
PrivateData1->DriverHandle[0]);
Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);
ConfigRequest = AllocateZeroPool (Size);
ASSERT (ConfigRequest != NULL);
AllocatedRequest = TRUE;
UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX",
ConfigRequestHdr, (UINT64)BufferSize);
FreePool (ConfigRequestHdr);
//-code-end
I add a debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest));
DEBUG((EFI_D_INFO,"\r\n"));
and the output will be:
construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=0000000000
If I add another debug message at the end of code:
DEBUG((EFI_D_INFO,"construct-ConfigRequest:"));
for(UINTN i=0;i<Size;i++)
{
DEBUG((EFI_D_INFO,"%c",ConfigRequest[i]));
}
DEBUG((EFI_D_INFO,"\r\n"));
and the output will be:
construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=0000000000000052
pa?pr╝ <_<_
my platform:
win10_x64 + udk2017 + vs2015
Umm, I'm a bit confused by your query.
* First, most DebugLib instances have an internal buffer with fixed size
(for the DebugPrint() function). If you try to log longer messages, they
will be truncated.
For example, in "MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c",
there is:
#define MAX_DEBUG_MESSAGE_LENGTH 0x100
Yes that's the root cause I guess.
The DebugLib depends on ReportStatusCode also has similar
max message length limitation.
(I don't really understand your situation because the first debug
message that you pasted does *not* look truncated.)
* Second, regarding the trailing garbage. You set "Size" to the number
of *bytes* required for a NUL-terminated CHAR16 config request string,
plus 32 CHAR16 objects. This is then correctly passed to both
AllocateZeroPool() and UnicodeSPrint(). However, in the loop where you
print individual CHAR16 objects, you also count up to the number of
*bytes* -- that's incorrect, the limit should be the number of CHAR16
objects (or the NUL-terminator, of course).
Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
--
Thanks,
Ray
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
