public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/394] New: wierd I/O-error handling in libio
@ 2004-09-20 22:10 peak at argo dot troja dot mff dot cuni dot cz
2004-09-26 12:43 ` [Bug libc/394] " drepper at redhat dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: peak at argo dot troja dot mff dot cuni dot cz @ 2004-09-20 22:10 UTC (permalink / raw)
To: glibc-bugs
1. {new,old}_do_write() & _IO_{new,old}_file_xsputn() cannot handle -1 from
_IO_SYSWRITE() even if -1 appears to be the expected way to signal errors (and
certain functions like fmemopen_write() do that)
2. read errors are recorded (_IO_ERR_SEEN) in _IO_{new,old}_file_overflow() and
_IO_file_xsgetn() (but not in _IO_default_xsgetn()!) while write errors are
recorded on a lower level--in _IO_{new,old}_file_write() (and this is impossible
to do with fopencookie()); are these inconsistencies intentional?
--
Summary: wierd I/O-error handling in libio
Product: glibc
Version: 2.3.3
Status: NEW
Severity: minor
Priority: P2
Component: libc
AssignedTo: gotom at debian dot or dot jp
ReportedBy: peak at argo dot troja dot mff dot cuni dot cz
CC: glibc-bugs at sources dot redhat dot com
http://sources.redhat.com/bugzilla/show_bug.cgi?id=394
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/394] wierd I/O-error handling in libio
2004-09-20 22:10 [Bug libc/394] New: wierd I/O-error handling in libio peak at argo dot troja dot mff dot cuni dot cz
@ 2004-09-26 12:43 ` drepper at redhat dot com
2004-10-07 21:07 ` peak at argo dot troja dot mff dot cuni dot cz
2005-09-23 16:35 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2004-09-26 12:43 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2004-09-26 12:43 -------
Which _IO_SYSWRITE implementation returns -1? Certainly not _IO_new_file_write.
And don't ask questions about the code, I have no time to answer those. If you
think you found a problem, write a test case.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://sources.redhat.com/bugzilla/show_bug.cgi?id=394
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/394] wierd I/O-error handling in libio
2004-09-20 22:10 [Bug libc/394] New: wierd I/O-error handling in libio peak at argo dot troja dot mff dot cuni dot cz
2004-09-26 12:43 ` [Bug libc/394] " drepper at redhat dot com
@ 2004-10-07 21:07 ` peak at argo dot troja dot mff dot cuni dot cz
2005-09-23 16:35 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: peak at argo dot troja dot mff dot cuni dot cz @ 2004-10-07 21:07 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From peak at argo dot troja dot mff dot cuni dot cz 2004-10-07 21:07 -------
Created an attachment (id=223)
--> (http://sources.redhat.com/bugzilla/attachment.cgi?id=223&action=view)
fmemopen() testcase
This programs creates a memory stream with a buffer 10 chars long and checks
what happens when too much data are written to it.
Case 1: 100 successful putc's, fflush after putc #100 fails, ferror not set
$ ./ts
fflush #100 failed: no err
final status: no err
INCORRECT (error detected by fflush but ferror not set)
Case 2: 100 successful putc's, no fflush, ferror not set, fclose fails
$ ./ts 100 100
final status: no err
fclose failed
CORRECT (error detected during implicit fflush in fclose)
Case 3: lots of putc's, no fflush, putc #8193 fails, ferror not set--WRONG
$ ./ts 100000 100000
putc #8193 failed: no err
final status: no err
INCORRECT (error detected by putc #8193 but ferror not set)
Any stream implemented using fopencookie() and using the documented way
(libc.info: Hook Functions) to report errors from cookie functions (return -1)
would exhibit similar errors.
--
http://sources.redhat.com/bugzilla/show_bug.cgi?id=394
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/394] wierd I/O-error handling in libio
2004-09-20 22:10 [Bug libc/394] New: wierd I/O-error handling in libio peak at argo dot troja dot mff dot cuni dot cz
2004-09-26 12:43 ` [Bug libc/394] " drepper at redhat dot com
2004-10-07 21:07 ` peak at argo dot troja dot mff dot cuni dot cz
@ 2005-09-23 16:35 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2005-09-23 16:35 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2005-09-23 16:35 -------
The current code on the trunk should behave correctly.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |FIXED
http://sourceware.org/bugzilla/show_bug.cgi?id=394
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-09-23 16:35 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-09-20 22:10 [Bug libc/394] New: wierd I/O-error handling in libio peak at argo dot troja dot mff dot cuni dot cz
2004-09-26 12:43 ` [Bug libc/394] " drepper at redhat dot com
2004-10-07 21:07 ` peak at argo dot troja dot mff dot cuni dot cz
2005-09-23 16:35 ` drepper at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).