wint_t has invalid definition?
Joseph S. Myers
jsm28@cam.ac.uk
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
jsm28@cam.ac.uk
More information about the Gcc-bugs
mailing list