svn commit: r205954 - head/include

Bruce Evans brde at
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 mailing list