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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
