Currently, fileno(3) is implemented as a macro in stdio.h: #define fileno(p) (!__isthreaded ? __sfileno(p) : (fileno)(p)) Per discussion with lichray, because this is a macro, it could cause namespace collision with C++ programs that uses the same name, and that could potentially a problem when porting applications to FreeBSD. POSIX, on the other hand, defines fileno as a function.
Not so clear-cut: "The following shall be declared as functions and may also be defined as macros. Function prototypes shall be provided." http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdio.h.html
I think that's pretty clear. It *must* be a function. It *may* also be a macro. It currently is a function and a macro, but the function is external and so if you #undef the macro you get worse performance. There are a number of cases like this, where we should be defining an inline function instead of a macro. This also makes building language bridges harder than it needs to be on FreeBSD.
By the way, libc++ has a load of #undef lines to work around this kind of thing for files like cmath. The Solaris libc headers are much nicer to work with from that perspective.
Bruce, almost none of what you have said is relevant for C++.
(In reply to David Chisnall from comment #4) Right now, to C++, the only issue left is whether the shortcut implementations can be called, since those macros are already being guarded against __cplusplus. The complexity of this change went beyond my expectation. And wrt performance, the cases actually matter are getc/putc...
(In reply to lichray from comment #5) Though macros are guarded against C++, they're not guarded against #undef :D also (i think) they're violating standards too. I'm changing getc/putc to function too :) and i think it will not be performance problem as in view of performance inline functions have no diff with macros.
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.