This is the mail archive of the
mailing list for the newlib project.
Re: [PATCH v3 01/24] Feature test macros overhaul: sys/features.h
- From: Craig Howland <howland at LGSInnovations dot com>
- To: <newlib at sourceware dot org>
- Date: Thu, 17 Mar 2016 12:09:51 -0400
- Subject: Re: [PATCH v3 01/24] Feature test macros overhaul: sys/features.h
- Authentication-results: sourceware.org; auth=none
- References: <1458011431-9460-1-git-send-email-yselkowi at redhat dot com> <1458011431-9460-2-git-send-email-yselkowi at redhat dot com> <56E98BA9 dot 2000906 at LGSInnovations dot com> <56EA6E6F dot 8090002 at cygwin dot com>
On 03/17/2016 04:44 AM, Yaakov Selkowitz wrote:
I agree, the usage should be in the synopsis sections. That would cover what
I've been calling the user aspect of documenting this. It is something that is
presently missing; not a fault with this patch but one that has been brought to
light by it. (And while it's not fair to expect it, you're probably the one in
the best position to add this information, since you had to have used it to
generate all the new gating information. Do you have summary notes on this that
you could include in an email to be a starting point for someone else to use if
you don't have time to be able to do it yourself?)
On 2016-03-16 11:36, Craig Howland wrote:
This all makes things more consistent (which is sorely needed),
but it seems to be lacking one major aspect: documentation in the
source. The email points to FEATURE_TEST_MACROS(7), but the newlib
developers and users are in the dark as to how to properly use this new
method--the man page is not mentioned anywhere in a file, for example.
feature_test_macros(7) only covers the public side of this, and while it is a
nice explanation of the various standards, it is not strictly necessary in
order to know how to use it. If you want more extensive documentation, then
the proper public macro(s) should be mentioned in the SYNOPSIS of each
function, as is done in throughout the Linux man-pages.
I am not saying that this is not a step forward in terms of consistency and
correctness. I was trying to say that in a narrow sense it has taken a step
backwards in terms of a user trying to figure out what they need to do to get a
particular gated function to be visible. (Sorry for not saying it well enough
initially.) Before a user could possibly (some times, but not all cases because
it is inconsistent) just look at the main header file to figure out what they
need to do, but now they definitely also need to go back to features.h and parse
the VISIBLE tree. See below for a further elaboration on this.
The prior method at least partly used user-level defines that were
self-explanatory, and this actually takes a step backwards from that.
No, this is a step forward both in terms of consistency and correctness.
Sorry, I was not clear enough. I did not state an assumption I had made. I
think that since the general Newlib documentation does not tell users how things
work in terms of function declaration visibility, that they then will go hunting
in the header files to see how they are gated--this is what I do. (I also
assume that users are not going to go other than Newlib as their first course of
action, as after all, while Newlib is a C library it is a different
implementation than any other. So while you might get some insight from looking
at a GLIBC or FreeBSD man page, they are not Newlib. So the user would first
look in the Newlib header files. You might also check others to gain insight,
but the Newlib source is its own definition.) So then the *VISIBLE macros are
what the user will see, as the user searches the headers due to lack of other
documentation. And, yes, the *VISIBLE macros are new from the point of view of
now being the primary gates rather than the mix of the old way. Yes, the new
*VISIBLE gates are more consistent than what was there before, but they are new
and unfamiliar to a Newlib-only person looking at the headers, and thus we're
back to the need for documentation to aid in the transition.
For example, __STRICT_ANSI is a compiler predefine that can be looked
up, and _POSIX_C_SOURCE can be found in POSIX. However, the user is now
confronted with the *_VISIBLE defines, but just what these mean is not
Users are *not* "confronted" with __*_VISIBLE, as those are private (internal)
macros, nor is that naming scheme new.
Yes, I am, but that's what a user will see hunting through the headers trying to
understand what they need to define.
(Some are more so than others, as ISOC99_SOURCE is pretty
obvious, but what does ATFILE_VISIBLE mean?)
You're mixing public and private (internal) macros here.
My point is that you did work to understand how the public macros map to the
*VISIBLE macros. I think it was non-trivial and of value. Let's get that
written down so that every developer does not need to re-do what you have done.
It not only saves time for them, but lessens the chance that they derive a
different answer than you did.
One specific example is _DEFAULT_SOURCE. It's said to deprecate _BSD_SOURCE and
_SVID_SOURCE, but why? And what does it really mean? The description given for
it is "POSIX-1.2008 with BSD and SVr4 extensions". But if you look at POSIX,
there is no such thing. Where should one look to know what it is? Is it a
Newlib invention? Or are we copying it from somewhere else that we need to
refer to to try and stay in sync? (We know from your overall reason for the
patch that it is from elsewhere, but the source doesn't say, so N years from now
someone looking would not know.)
In a similar manner, if a developer adds a function, what is the proper
way to label it with *VISIBLE?
The same thing I did to get this far: look at the Linux man-pages, and use the
__*_VISIBLE macros which correspond to the public macros indicated therein.
I agree, it is not a regression. But I submit that adding some developer-aiding
information is important so that all the hard work you've done on this does not
degenerate going forward. This is a very messy topic, and getting some more of
your hard-earned wisdom on this added as some extra comments will help to make
it somewhat less of a problem going ahead.
The comments at the start of features.h give a reasonable summary
for an informed user (so there is something on the user level), but
developer guidance on using VISIBLE is essentially non-existent.
Note that's not a regression.