[Bug libc/394] New: wierd I/O-error handling in libio

[Bug libc/394] New: wierd I/O-error handling in libio

[peak at argo dot troja dot mff dot cuni dot cz]

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.

[Bug libc/394] wierd I/O-error handling in libio

[drepper at redhat dot com]

------- 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.

[Bug libc/394] wierd I/O-error handling in libio

[peak at argo dot troja dot mff dot cuni dot cz]

------- 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.

[Bug libc/394] wierd I/O-error handling in libio

[drepper at redhat dot com]

------- 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.