[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.


More information about the freebsd-standards mailing list