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
^stddef.h,
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
latter:
- 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>.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
