[Bug 206146] fileno(3) should be implemented as a function; need to check other functions as well
Bruce Evans
brde at optusnet.com.au
Tue Jan 12 16:27:41 UTC 2016
On Tue, 12 Jan 2016 bugzilla-noreply at freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206146
>
> --- Comment #4 from David Chisnall <theraven at FreeBSD.org> ---
> Bruce, almost none of what you have said is relevant for C++.
The user or implementation is including <stdio.h> without understanding
its namespace and getting full pollution with POSIX support and
FreeBSD extensions.
I don't want to know about C++, but looked at the implementations in
<c++>. These only know about the C90 (and maybe C99) function-like
APIs that are required to exist as macros. These are handled by
#undefing them all.
Extensions should be handled by #defining _ANSI_SOURCE, _C99_SOURCE or
_C11_SOURCE before including <stdio.h>. <stdio.h> only has a tiny amount
of direct support for C++ (mainly __BEGIN_DECLS, etc.).
The c++ is also broken for most or all standard function-like
APIs that are not required to be macros. These are permitted to be
implemented using (safe) macros. #undefing all of these or knowing
which ones need to be #undefed takes more understanding of the C
namespace than defining _XXX_SOURCE.
gcc handled this better in 2003 or earlier. <c++/3.3/cstdio>
unconditionally #undef's all (?) 41 of the standard C90 function-like
APIs before reusing them in 'namespace std'. Later it does the
same for all (?) 5 extensions in C99. It doesn't seem to do anything
for POSIX extensions and I doubt that this is handled automatically.
Any pre-definitions of _XXX_SOURCE would hide POSIX and FreeBSD
extensions in all C headers.
Bruce
More information about the freebsd-standards
mailing list