Re: [PATCH 1/2] benchtests: Add wcrtomb microbenchmark

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 06/05/2022 10:36, Siddhesh Poyarekar wrote:
> On 06/05/2022 18:56, Siddhesh Poyarekar wrote:
>> On 06/05/2022 18:50, Adhemerval Zanella wrote:
>>>
>>>
>>> On 06/05/2022 09:59, Siddhesh Poyarekar wrote:
>>>> (Sorry I just committed it before I saw your message)
>>>>
>>>> On 06/05/2022 18:20, Adhemerval Zanella via Libc-alpha wrote:
>>>>>> +  /* 4-byte chars, because smileys are the universal language and we want to
>>>>>> +     ensure optimal performance with them 😊.  */
>>>>>> +  {"en_US.UTF-8",
>>>>>> +   L"😀😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏😐😑😒😓😔😕😖😗😘😙😚😛😜😝😞😟😠😡"}
>>>>>> +};
>>>>>
>>>>> Could you use use hexadecimal character escape in tests? Although gcc handle multiple
>>>>> -fexec-charset, trying to build it with a different compiler usually emits a lot of
>>>>> warnings.
>>>>>
>>>>
>>>> Hmm, I'm curious to know which compiler this breaks on; it's straight up UTF-8 so should parse just fine, no?
>>>
>>> I does not really breaks, but clang warns about character enconding (I forgot
>>> which was the specific error, I will check it). I have to fix a lot of internal
>>> usage to get a clean make check on clang [1].
>>>
>>> [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=058bb0d51c3f85041c7cbd14704f72003bdbdee9
>>>
>>
>> Ah, so that's all ISO-8859, it shouldn't warn on utf-8.
> 
> In any case, if you see warnings on this, please pass it on to me and I'll fix it but it seems wrong for clang to warn on this.

Yeah, the issue is ISO-8859 in fact.  The L'...' with UTF-8 does not trigger any
issue.