svn commit: r205954 - head/include
brde at optusnet.com.au
Fri Apr 16 09:33:00 UTC 2010
On Thu, 15 Apr 2010, David Schultz wrote:
> On Wed, Mar 31, 2010, Juli Mallett wrote:
>> Be like stdlib.h and bring in a wchar_t definition and use it to prototype
>> wcstoimax and wcstoumax, rather than spelling it __wchar_t. This is necessary
>> to use these functions in C++ where wchar_t is different to __wchar_t and is
>> a built-in type.
> I don't think this change is correct for C mode. POSIX says
> wchar_t is *supposed* to be defined by stdlib.h and wchar.h, but
> its definition is namespace pollution elsewhere.
C99 says the same, at least in old drafts. C99 also says that for the
functions in <inttypes.h> that use wchar_t, both <inttypes.h> and
<stddef.h> must be included (by giving both of these headers in the
synopses for these functions, and no explicit alternatives anywhere).
However, this is unusable and close to unimplementable, especially the
- including <inttypes.h> without including <stddef.h> should work when
these functions are not used. FreeBSD used to use the usual implementation
involving underscored named to make this case works without polluting
<inttypes.h> with wchar_t. It is hard to make this case work while
detecting the error in the case where these functions are used but
<stddef.h> is not included.
- it is even harder and even sillier to detect the error in the case where
these functions are used and some other header that declares wchar_t is
included, but <stddef.h> is not included :-). Perhaps fine print in
C99 overrides the silly literal requirement, but I couldn't find it.
POSIX (at least in old 2001 draft 7) is only slightly different here.
It only mentions <inttypes.h> in the synopses, but gives <wchar.h> in
examples. But current POSIX (at least in the most recent html man page
for wcstoimax found by google) has caught down to C99: it now specifies
<stddef.h> and <inttypes.h> in the synopsis, and doesn't say anything
about alternatives to <stddef.h> in the synopses, and doesn't say anything
special about wchar_t.
I couldn't find anything useful about this problem using google. I found
mainly confusion about it in FOSS mailing lists, with no signs of standards
being aware of it.
IMO, the functions using wchar_t should never have been put in
<inttypes.h>. The corresponding problem for <stdio.h> was carefully
avoided by putting all the stdio functions that use wchar_t in <wchar.h>
(where it causes corresponding problems for stdio types like FILE (*)).
However, these functions have been misplaced for so long that the
shouldn't be moved, and the easiest fix is to standardize the pollution.
(*) The problems for FILE in <wchar.h> are handled equally badly by
standards and equally well by FreeBSD (compared with old-FreeBSD for
wchar_t in <inttypes.h>). FILE would be namespace pollution in
<wchar.h>, and FreeBSD is careful not to add it, and standards require
inclusion of both <stdio.h> and <wchar.h> before using functions that
use both FILE and wchar_t, but the latter is unusuable and close to
unimplementable, as above. Now the functions are reasonably well
placed (you wouldn't want a <stdio-with-wchar.h> header just to hold
them), and again the easiest fix is to standardize the pollution.
At least the pollution wouldn't go all the way to <stdio.h>.
More information about the svn-src-all