Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

[Eric Blake]

On 02/22/2012 10:02 PM, Linda Walsh wrote:
> 
> 
> Eric Blake wrote:
> 
>>
>> Don't think of it as 'wide-int', rather, think of it as 'the integral
>> type that both contains wchar_t and WEOF'.  You cannot write 'signed
>> wint_t' nor 'unsigned 'wint_t'.
> 
> 
> ---
> ?? You say don't think of it that way, but unless I missed something,
> just like wchar stood for 'wide char', (and char's have always been
> signed or unsigned, (separate from short ints/unsigned short),  the
> term 'wint' would have come from wide int.  But ints have never been
> unsigned unless specifically prefixed as such... so wints shouldn't
> have the ambiguity that chars have.
> 
>  It may very well exist as unsigned somewhere -- but the implementer
> should be chained to a 1960's card punch and forced to write in cobol.
> 
> You still haven't mentioned anyplace where wint_t is an unsigned
> value.

Yes, I have:
https://lists.gnu.org/archive/html/bug-bash/2012-02/msg00070.html
"both glibc (32-bit wchar_t) and cygwin (16-bit wchar_t) use a 32-bit
unsigned int for wint_t."

$ printf '#include<wchar.h>\n' |gcc -E -|grep wint_t | head -n1
typedef unsigned int wint_t;

>   Is this a hypothetical issue?  I.e. in theory it could
> be unsigned , but in practice no one has ever made it so?

No, it is not hypothetical.  It is real.  wint_t can be either signed or
unsigned, and portable code cannot assume.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature