bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fwrite error reporting


From: Petr Vandrovec
Subject: fwrite error reporting
Date: Tue, 03 Apr 2001 18:55:01 -0700

Hi,
  during some tests with glibc-2.2.2 I also run to code which does:

int bytes_to_write;
char* pointer;

while (bytes_to_write > 0) {
  int tmp = bytes_to_write > 1048576 ? 1048576 : bytes_to_write;
  int count = fwrite(pointer, 1, tmp, outstream);
  if (count <= 0) {
    return FATAL_ERROR;
  }
  bytes_to_write -= count;
  pointer += count;
}

Unfortunately when underlying write() fails for some reason
(-EIO over NFS in my case) fwrite just returns 32768 although
no data were written and no data are stored in stream's buffer.

I believe that libio/fileops.c:new_do_write must handle return
error codes gracefully instead of smashing output buffer, as
data are unrecoverably lost in this case.

And another point, stdio library in this case sets ferror()
indication and refuses to do any more work on this stream
until clearerr or rewind. libio just does not care - so we just
get file which misses 32KB in the middle, although there was no
error reported to application (except one short write which
I assume is legal).

10965 fwrite("", 1, 1048576, 0x084f0a48 <unfinished ...>
10965 SYS_write(15, "", 32768)                    = -5
10965 <... fwrite resumed> )                      = 32768
10965 fwrite("", 1, 1048576, 0x084f0a48 <unfinished ...>
10965 SYS_write(15, "", 32768)                    = 32768
10965 SYS_write(15, "", 1015808)                  = 1015808
10965 <... fwrite resumed> )                      = 1048576

For now I'll just assume that every short write is unrecoverable
fatal problem, but it does not look like correct solution to me.
                                        Thanks,
                                                Petr Vandrovec
                                                address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]