public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* 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