Felix,
The UEFI Specification defines the HII String Protocol SetString() function to
have following function prototype:
typedef
EFI_STATUS
(EFIAPI *EFI_HII_SET_STRING) (
IN CONST EFI_HII_STRING_PROTOCOL *This,
IN EFI_HII_HANDLE PackageList,
IN EFI_STRING_ID StringId,
IN CONST CHAR8 *Language,
IN CONST EFI_STRING String,
IN CONST EFI_FONT_INFO *StringFontInfo OPTIONAL
);
The parameter String is of type EFI_STRING, and EFI_STRING is defined in the
UEFI Specification as:
typedef CHAR16 *EFI_STRING;
As Andrew pointed out, the UEFI Specification also states:
Table 6 lists the common data types that are used in the interface
definitions, and Table 7 lists their modifiers. Unless otherwise specified all
data types are naturally aligned. Structures are aligned on boundaries equal to
the largest internal datum of the structure and internal data are implicitly
padded to achieve natural alignment.
Since String is type EFI_STRING, which is a pointer to a CHAR16, and CHAR16 is
to be naturally aligned, this implies that the SetString() function requires
the String parameter to be a pointer to a naturally aligned CHAR16 buffer. This
means it is the caller's responsibility to guarantee that the String parameter
is aligned before calling SetString(). This same line of thinking applies to
all HII related APIs that make use of a parameter of type EFI_STRING or other
APIs that use a parameter of type CHAR16 *.
Can you provide details on why you do not think there are alignment
requirements for HiiString->SetString(). Maybe I am missing an exception
statement in the UEFI Specification?
Thanks,
Mike
-----Original Message-----
From: Felix Poludov [mailto:[email protected]]
Sent: Thursday, February 14, 2013 3:38 PM
To: [email protected]
Subject: Re: [edk2] How to align auto variables?
That's not necessarily, the end of the story.
There is a change that sooner or later that string will get passed to one of
the HII functions such as HiiString->SetString.
This will cause an ASSERT in the platform firmware, because guess which
function the HII driver is using to get the string length :-)
The UEFI specification does not require alignment for HiiString->SetString
argument, so a caller can pass an unaligned string.
On the other hand, it's quite natural for an EDKII HII driver developer to use
StrLen from the BaseLib to get the string length...
So, there appears to be no wrong-doings, yet there is an ASSERT.
Thanks
Felix
PS We've actually seen this happening...
-----Original Message-----
From: Prakash, Sathya [mailto:[email protected]]
Sent: Thursday, February 14, 2013 2:43 PM
To: [email protected]
Subject: Re: [edk2] How to align auto variables?
I am planning to remove the ASSERTS from the library code for my purpose, I am
compiling only for X64.
Thanks
Sathya
-----Original Message-----
From: Tim Lewis [mailto:[email protected]]
Sent: Thursday, February 14, 2013 10:28 AM
To: [email protected]
Subject: Re: [edk2] How to align auto variables?
Sathya -- I would suggest instead that you simply write your own strcpy
function which uses UINT8-level access instead of UINT16.
Tim
-----Original Message-----
From: Prakash, Sathya [mailto:[email protected]]
Sent: Thursday, February 14, 2013 9:24 AM
To: [email protected]
Subject: Re: [edk2] How to align auto variables?
I just checked the reason for un-alignment. There are number of CHAR16 arrays
inside my VFR structures to which I need to copy information, like controller
vendor info etc. Since they are used in extractconfig calls in constructing
byte array back using HiiConfigRouting->BlockToConfig, I must need to keep
them as byte aligned.
So it looks like I need to manually re-arrange the structures in such a way
that the CHAR16 arrays are 2 bytes aligned.
Thanks
Sathya
-----Original Message-----
From: David Woodhouse [mailto:[email protected]]
Sent: Thursday, February 14, 2013 12:58 AM
To: Andrew Fish
Cc: [email protected]
Subject: Re: [edk2] How to align auto variables?
On Wed, 2013-02-13 at 16:59 -0800, Andrew Fish wrote:
> I think the best solution may be to to have a PCD feature flag to
> control this feature. If you are constructing code in the edk2 you
> mostly want it to be generic and we can default to turning it on. If
> you are construction code with looser rules you can turn it off.
I'm dubious about that idea. It is *often* the case that code one expects *not*
to have to port, *does* end up being used in situations which weren't
originally anticipated. Deliberately being lax about one's own code is one
thing, but for us to implement a generic way to *enable* engineers to be
deliberately lax about their code is another. That does not sound like a recipe
for future happiness.
It's not as if writing portable code which obeys the alignment constraints of
the C language is particularly difficult, surely?
Of course, in this particular case it probably serves us right for using this
UTF-16 abomination instead of UTF-8... but that's a different story :)
--
dwmw2
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the
hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the
hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the
hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
The information contained in this message may be confidential and proprietary
to American Megatrends, Inc. This communication is intended to be read only by
the individual or entity to whom it is addressed or by their designee. If the
reader of this message is not the intended recipient, you are on notice that
any distribution of this message, in any form, is strictly prohibited. Please
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and
then delete or destroy all copies of the transmission.
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
