[U-Boot] [PATCH v0 03/20] short-wchar

[Rob Clark]

On Fri, Aug 4, 2017 at 4:28 PM, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 08/04/2017 09:31 PM, Rob Clark wrote:
>> For now, pending conclusion on proposal about using c11 and u"string"
>> instead of L"string" plus -fshort-wchar.
>>
>> Background: UEFI uses utf16 strings universally.  An UEFI implementation
>> that does not use -fshort-wchar has to do a lot of cumbersome charset
>> conversion back/forth.  Mixing object files that use -fshort-wchar and
>> others that do not is a bad idea (and gcc will warn about it).  There
>> are 3 reasonable solutions that I can think of:
>>
>>  1) Use -fshort-wchar across the board.  We don't dynamically link
>>     against other shared libraries at runtime, so there isn't much
>>     downside to this approach.  Heinrich brought up ext4, which uses
>>     utf32, but I guess this mostly matters for fs_ls(), and it does
>>     not seem so bad for it to do utf32->utf8 conversion.
>>
>>  2) Use -fshort-wchar only if CONFIG_EFI_LOADER=y.. UEFI only requires
>>     fat/vfat so we don't need ext4 and efi loader at the same time.
>>
>>  3) Go with Heinrich's suggestion of requiring c11.  Possibly this
>>     requirement could be loosened to only require c11 for efi loader.
>>     This seems like the best approach, and at least no one has so
>>     far brought up any objection to his proposal.
>>
>> Not-signed-off-by: Rob Clark <robdclark at gmail.com>
>
> Do I understand you right?
> You do not want the current version of the patch series merged?

nope, I fully expect review comments and updates, hence calling it
"v0".. I just don't want it to be ignored, as is the tendency for
large RFC's on other lists that I am on.  Hence the
"Not-signed-off-by" ;-)

> It might have been better to replace [PATCH] by [RFC] in the subject
> lines of the patch set in this case.
>
> I am currently trying to find out if the switch to C11 is possible, cf.
> https://travis-ci.org/xypron2/u-boot/builds/261098363.
>
> Unfortunately Travis uses gcc 4.8.2 for some jobs which does not yet
> support C11.
>
> Furthermore there seems to be some problem in disk/part_efi.c with
> PARTITION_SYSTEM_GUID.

hmm, link/pastebin error, and I can have a look?  On my wip branch
that included this patchset, plus other bits needed to make it work on
db410c, I didn't see any such issues, but I might have screwed
something up in splitting up the db410c and related fixes from the
efi_loader patchset.

I do have some regressions on a couple of the vexpress boards, which
are totally unrelated to the patch that introduces the regression and
I cannot reproduce locally (although locally I have newer gcc and
qemu).  See [1] which is introduced by patch 15.  I'm pretty sure this
is a problem with the test environment (either gcc or qemu), but not
quite sure what to do about it.

[1] https://travis-ci.org/robclark/u-boot/jobs/260997492

BR,
-R

> Best regards
>
> Heinrich
>
>> ---
>>  config.mk | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/config.mk b/config.mk
>> index b77d58903c..5ad9e7198d 100644
>> --- a/config.mk
>> +++ b/config.mk
>> @@ -74,7 +74,7 @@ endif
>>  RELFLAGS := $(PLATFORM_RELFLAGS)
>>
>>  PLATFORM_CPPFLAGS += $(RELFLAGS)
>> -PLATFORM_CPPFLAGS += -pipe
>> +PLATFORM_CPPFLAGS += -pipe -fshort-wchar
>>
>>  LDFLAGS += $(PLATFORM_LDFLAGS)
>>  LDFLAGS_FINAL += -Bstatic
>>
>