> On Mar 21, 2016, at 7:58 PM, Gao, Liming <liming....@intel.com> wrote:
>
> Leif:
> I agree your understanding. To follow UEFI spec, I think we should update
> CHAR8 as the unsigned type in its definition for all ARCH ProcessorBind.h in
> MdePkg. If so, we don't need to add compiler option in tools_def.template.
>
I'm not sure, but does not the compiler flag defined the sign of the string
char literals? It would seem we might need to define the sign of CHAR8 and the
sign of strings *CHAR8 *a = "String"
For example:
~/work/Compiler>cat string.c
unsigned char *a = "a test";
signed char *b = "b test";
char *c = "c test";
~/work/Compiler>clang string.c -S
string.c:2:16: warning: initializing 'unsigned char *' with an expression of
type 'char [7]' converts between pointers to integer
types with different sign [-Wpointer-sign]
unsigned char *a = "a test";
^ ~~~~~~~~
string.c:3:16: warning: initializing 'signed char *' with an expression of type
'char [7]' converts between pointers to integer types
with different sign [-Wpointer-sign]
signed char *b = "b test";
^ ~~~~~~~~
2 warnings generated.
So actually it looks like clang is trying to enforce the C definition of char
to catch bugs?
Thanks,
Andrew Fish
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
> Lindholm
> Sent: Thursday, March 17, 2016 9:36 PM
> To: Laszlo Ersek
> Cc: edk2-devel (edk2-devel@lists.01.org)
> Subject: Re: [edk2] signedness of CHAR8
>
> On Thu, Mar 17, 2016 at 01:41:12PM +0100, Laszlo Ersek wrote:
>> On 03/17/16 13:34, Leif Lindholm wrote:
>>> On Thu, Mar 17, 2016 at 12:16:31PM +0000, Leif Lindholm wrote:
>>>> So, as further fallout from my -Weverything experiments, I've come
>>>> across this...
>>>>
>>>> Ia32 and X64 ProcessorBind.h (BaseTools and MdePkg) both define CHAR8 as
>>>> 'char'.
>>>> ARM and AArch64 both do the same.
>>>>
>>>> However, default 'char' signedness is unsigned in the ARM
>>>> architectures, and signed in the others.
>>>>
>>>> Meanwhile, the UEFI specification describes CHAR8 as
>>>> ---
>>>> 1-byte character. Unless otherwise specified, all 1-byte or ASCII
>>>> characters and
>>>> strings are stored in 8-bit ASCII encoding format, using the
>>>> ISO-Latin-1 character
>>>> set.
>>>> ---
>>>>
>>>> Now, ISO-Latin-1 holds values all the way up to 255, which clearly
>>>> does not fit into a signed 8-bit char.
>>>>
>>>> Would I be correct in my interpretation that Ia32/X64 should be
>>>> defining CHAR8 as 'unsigned char', or am I losing my mind?
>>>
>>> I'll reply to myself.
>>>
>>> BaseTools/Conf/tools_def.template sets -funsigned-chars for X64/Ia32 -
>>
>> Where? I can only see that for XCODE5.
>
> I stand corrected.
>
> /
> Leif
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
