Re: Signedness of wchar_t and wint_t leads to problems with gcc -Wsign-conversion

[Zack Weinberg <zackw at panix dot com>]

On Mon, Nov 21, 2016 at 8:46 AM, Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
> On 11/21/2016 02:28 PM, Andreas Schwab wrote:
>> On Nov 21 2016, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> wrote:
>>> On 11/21/2016 02:01 PM, Andreas Schwab wrote:
>>>> On Nov 21 2016, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> wrote:
>>>>
>>>>> So, I'm not quite clear on the point that you are making in your
>>>>> second point. Given code such as:
>>>>>
>>>>>     wchar_t w;
>>>>>     ...
>>>>>     if (iswlower((wint_t) w) ....
>>>>>
>>>>> Do you mean that the standards are saying that casting to wint_t here
>>>>> is guaranteed to be correct? I can't see the line of reasoning that
>>>>> leads there.
>>>>
>>>> Any valid value of wchar_t is representable by wint_t.  I cannot find
>>>> any more convincing argument.
>>>
>>> Yes, but is a sign-extended wchar_t a valid value?
>>
>> A valid value of wchar_t is a valid value.
>
> Sorry, that makes me no wiser :-(. You snipped the question
> whose answer might help me:
>
> To put things another way, why is this scenario different from
> the islower() example, where the cast to '(unsigned char)' is
> needed in portable code?

It's clear to me that Andreas believes that `iswlower((wint_t) w)` is
required to do the Right Thing, and off the top of my head, that
interpretation of the standard makes more sense than any alternative.

However, it is not clear to me that actual implementations honor that
requirement.  Consider the case where wchar_t is signed short (this
hypothetical implementation is limited to the BMP), wint_t is signed
int, and WEOF == ((wint_t)-1).  Then (wint_t)U+FFFF is
indistinguishable from WEOF.  Yes, U+FFFF is a reserved codepoint, but
it's still wrong for it to collide.

I would not want to swear that this never happens in real life without
an exhaustive audit of existing implementations.

zw