* Re: [PrintLib] Question about ASSERT_UNICODE_BUFFER [not found] <F745BF38-5416-4DD5-B5FC-146633C5F4B0@linaro.org> @ 2017-12-01 17:23 ` Kinney, Michael D 2017-12-04 1:24 ` Heyi Guo 0 siblings, 1 reply; 2+ messages in thread From: Kinney, Michael D @ 2017-12-01 17:23 UTC (permalink / raw) To: heyi.guo, edk2-devel@lists.01.org, Kinney, Michael D; +Cc: Gao, Liming Gary, The correct solution is to align the Unicode string buffer before using those APIs. The assert for unaligned Unicode string has been in place for over 10 years, and we have always been able to address this type of issue by fixing the calling code. Mike From: heyi.guo [mailto:heyi.guo@linaro.org] Sent: Thursday, November 30, 2017 10:58 PM To: edk2-devel@lists.01.org Cc: Gao, Liming <liming.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com> Subject: [PrintLib] Question about ASSERT_UNICODE_BUFFER Hi folks, I think platforms supported in EDK2 should enable unaligned data access, so a CHAR16 * pointer still works even if the pointer itself is not aligned by 2. Therefore, can we remove ASSERT_UNICODE_BUFFER statements in PrintLib for Unicode operations? If the platform doesn't support unaligned access, it can generate some kind of exception instead of software assert. The background is that we are importing a 3rd party driver and it packs a unicode string buffer into a structure, and #pragma pack(1) is used around the definition of this structure. So the alignment of the string buffer depends on the address of the whole structure and the members before it; it happened to be not aligned and we got assert during system post. Please let me know your comments. Thanks, Gary (Heyi Guo) ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PrintLib] Question about ASSERT_UNICODE_BUFFER 2017-12-01 17:23 ` [PrintLib] Question about ASSERT_UNICODE_BUFFER Kinney, Michael D @ 2017-12-04 1:24 ` Heyi Guo 0 siblings, 0 replies; 2+ messages in thread From: Heyi Guo @ 2017-12-04 1:24 UTC (permalink / raw) To: Kinney, Michael D, edk2-devel@lists.01.org; +Cc: Gao, Liming Thanks for your confirmation. Regards, Gary (Heyi Guo) 在 12/2/2017 1:23 AM, Kinney, Michael D 写道: > > Gary, > > The correct solution is to align the Unicode string buffer before > using those APIs. > > The assert for unaligned Unicode string has been in place for over 10 > years, and we have always > > been able to address this type of issue by fixing the calling code. > > Mike > > *From:*heyi.guo [mailto:heyi.guo@linaro.org] > *Sent:* Thursday, November 30, 2017 10:58 PM > *To:* edk2-devel@lists.01.org > *Cc:* Gao, Liming <liming.gao@intel.com>; Kinney, Michael D > <michael.d.kinney@intel.com> > *Subject:* [PrintLib] Question about ASSERT_UNICODE_BUFFER > > Hi folks, > > I think platforms supported in EDK2 should enable unaligned data > access, so a CHAR16 * pointer still works even if the pointer itself > is not aligned by 2. Therefore, can we remove ASSERT_UNICODE_BUFFER > statements in PrintLib for Unicode operations? If the platform doesn't > support unaligned access, it can generate some kind of exception > instead of software assert. > > The background is that we are importing a 3rd party driver and it > packs a unicode string buffer into a structure, and #pragma pack(1) is > used around the definition of this structure. So the alignment of the > string buffer depends on the address of the whole structure and the > members before it; it happened to be not aligned and we got assert > during system post. > > Please let me know your comments. > > Thanks, > > Gary (Heyi Guo) > ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-12-04 1:23 UTC | newest] Thread overview: 2+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <F745BF38-5416-4DD5-B5FC-146633C5F4B0@linaro.org> 2017-12-01 17:23 ` [PrintLib] Question about ASSERT_UNICODE_BUFFER Kinney, Michael D 2017-12-04 1:24 ` Heyi Guo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox