[PATCH v2 4/5] efi: Use 16-bit unicode strings

[Tom Rini]

On Sun, Aug 01, 2021 at 04:54:49PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 31 Jul 2021 at 21:28, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sun, Jul 18, 2021 at 09:36:42PM -0400, Tom Rini wrote:
> > > On Mon, Jul 19, 2021 at 03:07:50AM +0200, Heinrich Schuchardt wrote:
> > > > On 7/19/21 3:01 AM, Tom Rini wrote:
> > > > > On Mon, Jul 19, 2021 at 02:41:46AM +0200, Heinrich Schuchardt wrote:
> > > > > > On 7/18/21 10:14 PM, Simon Glass wrote:
> > > > > > > At present we use wide characters for unicode but this is not necessary.
> > > > > > > Change the code to use the 'u' literal instead. This helps to fix build
> > > > > > > warnings for sandbox on rpi.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > > Suggested-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > > > > >
> > > > > > According to https://en.cppreference.com/w/c/language/string_literal u""
> > > > > > literals are supported since C11. In our Makefile we have CSTD_FLAG :=
> > > > > > -std=gnu11.
> > > > > >
> > > > > > Once we have changed all u"" to L"" we can remove -fshort-wchar from our
> > > > > > Makefiles.
> > > >
> > > > Sorry, I meant 'change4 all L"" to u""'.
> > > >
> > > > -fshort-wchar interpretes all L"" as 16bit strings.
> > >
> > > Ah, OK.  So, still, time for an spatch?
> >
> > So to be clear here, I would like to see this fixed with an spatch as
> > the way to solve this tree-wide.
> 
> Can you please explain what you want done with spatch? So far as i can
> tell, I changed all L strings to u strings. What else is needed?

It was unclear to me that you fixed the problem tree-wide here.  If this
was all of them, tree-wide, please follow-up dropping -fshort-wchar from
the Makefile please.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210801/ed00ee45/attachment.sig>