wint_t has invalid definition?

Joseph S. Myers
Tue Oct 10 09:49:00 GMT 2000

On Tue, 10 Oct 2000, Todd Vierling wrote:

> The Single UNIX Specification, version 2, states for <wchar.h>:
>   wint_t
>   An integral type capable of storing any valid value of wchar_t, or WEOF.
> Note that NetBSD defines _BSD_WINT_T_ to make its definition using the same
> semantics as _BSD_SIZE_T_, so this macro should be used to typedef it.  (I
> can supply a patch for this, if desired.)

For current CVS, you should also send a patch to define WINT_TYPE.  (GCC
has gained an internal notion of wint_t so it can check %lc printf
formats.  Note there's a bug in one example in the C standard in this
area: the example presumes that wint_t is the result of applying the
default promotions to wchar_t, but it needn't be so; it need only itself
be unchanged under the default promotions.)

> However, the SUSv2 citation implies, to me, that wint_t should also default
> to the same type as wchar_t--in other words, (signed) int--as the unsigned
> version cannot properly store the possibly negative wchar_t values.

What character set in what locale you support uses negative character
values?  In ISO 10646 values outside the range 0 to 2^31 - 1 are invalid.

The default is a valid choice of type according to the C standard; now
that you can define WINT_TYPE, changing the default seems unnecessary.

The existence of the definition in <stddef.h> was a bug (ISO C does not
permit wint_t to be defined there); in current CVS it will only be defined
by that header if __need_wint_t is defined first.

Joseph S. Myers

More information about the Gcc-bugs mailing list