Bug 206146 - fileno(3) should be implemented as a function; need to check other functions as well
Summary: fileno(3) should be implemented as a function; need to check other functions ...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-standards (Nobody)
URL: https://reviews.freebsd.org/D4980
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-12 06:45 UTC by Xin LI
Modified: 2018-05-29 12:37 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xin LI freebsd_committer freebsd_triage 2016-01-12 06:45:19 UTC
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.
Comment 1 Dag-Erling Smørgrav freebsd_committer freebsd_triage 2016-01-12 09:46:39 UTC
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
Comment 2 David Chisnall freebsd_committer freebsd_triage 2016-01-12 09:57:10 UTC
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.
Comment 3 David Chisnall freebsd_committer freebsd_triage 2016-01-12 10:02:18 UTC
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.
Comment 4 David Chisnall freebsd_committer freebsd_triage 2016-01-12 15:22:57 UTC
Bruce, almost none of what you have said is relevant for C++.
Comment 5 lichray 2016-01-30 05:45:28 UTC
(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...
Comment 6 Mahdi Mokhtari freebsd_committer freebsd_triage 2016-01-30 08:16:09 UTC
(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.
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:44:09 UTC
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.