This is the mail archive of the
mailing list for the glibc project.
Re: RFC on enforcing best-practice through wrappers? [PR15819, PR15722]
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 6 Nov 2014 14:28:23 -0800 (PST)
- Subject: Re: RFC on enforcing best-practice through wrappers? [PR15819, PR15722]
- Authentication-results: sourceware.org; auth=none
- References: <oroasm6pw9 dot fsf at free dot home>
Prefer inlines to macros. Clean up header tangles and internal
arrangements as necessary to make it doable. There is probably a lot to
unwind there and to just make progress quickly it will often be easier
to use a macro. I'm sure there will be cases where we're happy enough
to just have new macro use because it makes things better without
waiting for a lot of hair-pulling header refactoring. But it is the
right long-term direction to have fewer function-like macros when they
can be inline functions instead, and the effort put into the header
cleanups should pay dividends in terms of easier maintenance and
code-reading aside from the specific inline enablement motivating the work.
I think it would be better to move towards more internal-only headers
and less having extra magic in include/foo.h wrapper headers. Ideally I
think those would only be for hidden_proto and the like--where it's not
changing the API offered by #include <foo.h> beyond __-prefixed names
where that is appropriate for name space issues--__foo being wholly
identical to foo, not a wrapper doing something slightly different.
It's a bonus that it makes it less likely you'll encounter
mutually-dependent #include hell, but for me the chief motivation is
ease of understanding the code: If a source file does #include <foo.h>
for a standard <foo.h> and then uses standard foo.h APIs (or ones that
look just like them except for something trivial-seeming like the __
prefix), then the reader who knows the standards but not every corner of
our internal headers should not be misled about what functions are being
called and what their exact APIs are.
Once we have a clean and happy situation for a particular interface in
our internal code, then we can carefully consider the potential utility
of offering a new public API that brings similar benefits to application
code. But I don't think we should be eager to try to find such things,
while we certainly should be eager to do internal cleanups.