[U-Boot] [U-Boot, v0, 07/20] vsprintf.c: add wide string (%ls) support

[Rob Clark]

On Wed, Aug 9, 2017 at 9:48 AM, Alexander Graf <agraf at suse.de> wrote:
>
>
>> Am 09.08.2017 um 14:38 schrieb Rob Clark <robdclark at gmail.com>:
>>
>>> On Tue, Aug 8, 2017 at 6:03 PM, Heinrich Schuchardt <xypron.glpk at 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:
>>
>> 1) 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