Andrew: Thanks for your point. I verify this change with VS2015 and GCC49 on IA32 arch. There is no warning report. So, I think the compiler option is not required for all tool chains and all archs. But, this is not true for CLANG. It may not be true for ARM. So, I suggest we add option -funsigned-char for every tool chain and every arch to ensure char is unsigned. For VS tool chain, /J (Default char Type Is unsigned) option. can be used. And, we also update CHAR8 definition with unsigned char to clearly follow UEFI spec.
Thanks Liming > -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of > Andrew Fish > Sent: Tuesday, March 22, 2016 11:33 AM > To: Gao, Liming > Cc: Kinney, Michael D; edk2-devel ([email protected]); Rothman, > Michael A; Laszlo Ersek; Leif Lindholm > Subject: Re: [edk2] signedness of CHAR8 > > > > On Mar 21, 2016, at 7:58 PM, Gao, Liming <[email protected]> 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:[email protected]] On Behalf Of > Leif Lindholm > > Sent: Thursday, March 17, 2016 9:36 PM > > To: Laszlo Ersek > > Cc: edk2-devel ([email protected]) > > 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 > > [email protected]<mailto:[email protected]> > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
