This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/12724] fclose violates POSIX 2008 on seekable input streams


http://sourceware.org/bugzilla/show_bug.cgi?id=12724

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 17 Jan 2014, eblake at redhat dot com wrote:

> Any word on when this will be fixed?

When I started going through open "math" bugs a couple of years ago, 
fixing them and identifying underlying issues (with the implementation, 
test coverage, etc.) and other bugs in the course of fixing them, I was 
hoping for other people similarly to pick up the roles of glibc experts in 
particular areas, go through open bugs, fix them, file bugs for issues 
found, improve test coverage, understand the strengths and weaknesses of 
glibc in those areas and use that understanding to seek out and fix 
classes of bugs that seem likely to be present (without waiting for users 
to find and report them).

I still hope for people to pick up such roles.  One area needing an expert 
to take on leadership in resolving known issues is stdio.  Another is 
POSIX conformance, including going through clarifications / changes 
resulting from issues reported against various POSIX versions to ensure 
they are properly reflected in glibc, and bugs filed if not (and then, in 
future, to ensure bugs get filed for all future POSIX clarifications / 
changes indicating that a glibc change is needed).  Related to that is 
tracking new feature additions in POSIX (both between past revisions and 
in future ones) and ensuring we understand what features are missing from 
glibc.  Each component in Bugzilla could do with at least one expert.  
"libc" - miscellaneous bugs - needs a generalist who will, inter alia, 
seek consensus on questions of whether bugs that are really feature 
requests reflect features we do or do not want to have.

So: I'd expect this bug to be fixed after someone takes the lead on fixing 
it, possibly as part of taking the lead more generally on sorting out 
stdio or POSIX conformance issues, and including analysis of the 
compatibility issues and getting consensus on what might need doing for 
compatibility with existing binaries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]