On Wed, Aug 9, 2017 at 9:48 AM, Alexander Graf agraf@suse.de wrote:
Am 09.08.2017 um 14:38 schrieb Rob Clark robdclark@gmail.com:
On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 08/04/2017 09:31 PM, Rob Clark wrote:
@@ -528,8 +549,13 @@ repeat: continue;
case 's':
str = string(str, end, va_arg(args, char *),field_width, precision, flags);
if (qualifier == 'l') {%ls refers to wchar with implementation dependent width in the C standard. There is no qualifier for 16-bit wchar. Couldn't we use %us here in reference to the u-notation ( u'MyString' ). This would leave the path open for a standard compliant '%ls'.
So two drawbacks I'm running into when converting to c11 u"string" style, compared to the -fshort-wchar:
- with -fshort-wchar plus %ls, gcc knows how to typecheck the
printf/sprintf/etc args 2) introducing a non-standard conversion character (since there doesn't seem to be a standard one) means we need to drop -Wformat
So far, afaict, the only argument against -fshort-wchar seems to be that someday ext4 might support utf32 filenames? (And really -fshort-wchar doesn't preclude that. So I'm not sure this is a valid argument.)
So independent of c11 (which might be a good idea for other reasons), I'm back to thinking we should use -fshort-wchar. Possibly as a kconfig option that EFI_LOADER selects.. or possibly just unconditionally.
Thoughts?
If we select it, I'd rather have it be unconditional, to not oprn potential for undetected breakage.
I could go either way on kconfig option vs unconditional -fshort-wchar. Although as far as breakage, that seems pretty solvable by adding a fallback.efi -> grub.efi test, and maybe something that exercises device-path-to-text, in travis.
I suppose it might be useful, for example, for TINY_PRINTF to depend on !CC_SHORT_WCHAR? Not sure.
I'll include a patch w/ kconfig option in my patchset for now, but happy to drop it if folks want to do -fshort-wchar unconditionally.
BR, -R