On 03/17/16 13:16, 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.
In "BaseTools/Conf/tools_def.template", the ARM toolchains are instructed to use signed chars. DEFINE GCC_ARM_CC_FLAGS = ... -fsigned-char ... DEFINE GCC_AARCH64_CC_FLAGS = ... -fsigned-char ... DEFINE RVCT_ALL_CC_FLAGS = ... --signed_chars ... > 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? ARM and AARCH64 seem to be consistent with Ia32 and X64 (when the latter are built for with GCC), they all use signed chars. However, that doesn't seem to match Latin1; a comparison like (ch1<ch2) will break if "ch1" has value 97 (Latin1 for 'a') and "ch2' has value -31 (should be 225, for 'รก'). ... For added fun, the XCODE5 options (for Ia32/X64) include "-funsigned-char" ;) Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
