svn commit: r227487 - head/include

[Bruce Evans]

On Mon, 14 Nov 2011, David Schultz wrote:

> On Mon, Nov 14, 2011, David Chisnall wrote:
>> On 14 Nov 2011, at 18:02, David Schultz wrote:
>>
>>> On Mon, Nov 14, 2011, Dimitry Andric wrote:
>>>> On 2011-11-14 09:21, Stefan Farfeleder wrote:
>>>>> On Sun, Nov 13, 2011 at 04:18:48PM +0000, David Chisnall wrote:
>>>>>> Author: theraven
>>>>>> Date: Sun Nov 13 16:18:48 2011
>>>>>> New Revision: 227487
>>>>>> URL: http://svn.freebsd.org/changeset/base/227487
>>>>>>
>>>>>> Log:
>>>>>>  The spec says that FILE must be defined in wchar.h, but it wasn't.  It
>>>>>>  is now.  Also hide some macros in C++ mode that will break C++
>>>>>>  namespaced calls.
>>>>>>
>>>>>>  Approved by:	dim (mentor)
>>>>>
>>>>> I think this change is wrong. Whic spec are you referring to? C99
>>>>> defines FILE only in 7.19.1#2 (stdio.h). In other headers FILE is used
>>>>> as parameter type for functions but that does not mean it is exported to
>>>>> user space.

Also, this change doesn't even declare `FILE'.  It only declares an
incomplete struct for `FILE', just like the old version except for
a different spelling which gives namespace pollution that was carefully
avoided.

>>>> http://pubs.opengroup.org/onlinepubs/007908799/xsh/wchar.h.html

Just another bug in POSIX.  Another bug in it is its wording, which
is either too fuzzy or too strict.  It says that FILE is defined (sic)
as "described in <stdio.h>".  If this is interpreted strictly, then
it says that <wchar.h> must declare FILE completely iff <stdio.h>
declares it completely.  FILE should be opaque, so it should not be
declared completely in either, but FreeBSD still supports old optimized
inline or macro versions for a few of the interfaces in <stdio.h>, so
it must declare FILE completely in <stdio.h>.  Thus POSIX strictly
requires FILE to be declared completely in <wchar.h> too.  But nothing
in <wchar.h> needs to dereference FILE, so <wchar.h> doesn't need to
declare it completely.  I doubt that POSIX is so broken as to require
this intentionally.

>>> It's a niggling detail, but that's an extension to the C standard,
>>> so properly speaking, it belongs in an
>>>  #if __POSIX_VISIBLE >= 200809 || XSI_VISIBLE
>>> (or something like that).  The formals were struct __sFILE *
>>> instead of FILE * for that reason -- see r103177.
>>>
>>> P.S. You're looking at a very old version of POSIX.  Check out:
>>>     http://pubs.opengroup.org/onlinepubs/9699919799/

Too hard to search using lynx.

>> The C99 and C1x specifications both seem to require stdio.h to be included before wchar.h.  I think this therefore places including wchar.h and not stdio.h in the category of undefined (or, at least, not defined) behaviour, so we are free to do anything in this case.  I would say that accepting the code and working as the programmer expected is the least harmful thing to do here.  This is what Darwin libc does (actually, it #includes stdio.h in wchar.h).

Just another bug in Darwin.  FreeBSD had the full namespace pollution
from <stdio.h> too, until this was fixed in r103177.

> The C99 standard has plenty of examples of programs including
> <wchar.h> but not <stdio.h>.  The latter is only required to call
> the functions that take a FILE * parameter.  It's mostly an

Not even that in FreeBSD (but C99 and portability requires it).  The
functions can be called without knowing a complete declaration of FILE
or anything else in <stdio.h>.  E.g., getwc(NULL), or more usefully,
getwc(fp) where fp is a FILE * passed as a parameter to the function
that calls getwc().  This depends on the implementation detail that
none of the functions dereferences FILE *.  If we want to punish
unportable callers that don't include <stdio.h> strictly before including
<wchar.h> and using one of the functions, perhaps that can be arranged.

> academic point because no sane programmer would ever create a new
> type named FILE, but FreeBSD actually did right by C99 before you
> reverted r103177.

Bruce