On 22/07/11 16:22, Joern Rennecke wrote:
I have to disagree, library issue means that it's an issue with the
library, not gcc.
It still makes sense to clarify the language to indicate that, depending on
the library used, this might be, in fact, a library non-issue.
We might be interpreting this differently. When I you it's a "library
issue", I understand it as begin something that has to do with the
library, not that it is a definite problem with the library. Therefore
if I want to see what's the feature status I should check the library
documentation. I didn't think that saying it is a library issue would
mean that it is definitely broken/missing in the library.
Then again my native language is not english. However, by raising this
you're proving your point. If we can avoid different interpretations
then better.
I agree that trying to track every library there would be a maintenance
burden, but giving one example of a library that works is meaningful.
And, since GCC is still a GNU project, mentioning the status of GNU libc
doesn't seem that arbitrary.
Even just listing the status of a single feature from GNU libc might be
dangerous. You're duplicating information that's probably available in
the manual anyway and risk publicizing out-dated information. Also,
you'll need someone to volunteer to keep track of the status of every
feature in glibc that's listed a library issue in the c99 page. A better
way to do this if you want to mention glibc would be to link to glibc
documentation directly. Something like:
"Status of this feature in glibc <http://.../libc/manual/...>"
--
PMatos