Re: libstdc++/2913

Re: libstdc++/2913

[pme]

The following reply was made to PR libstdc++/2913; it has been noted by GNATS.

From: pme@gcc.gnu.org
To: donut@azstarnet.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  pme@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/2913
Date: 6 Jun 2001 23:50:17 -0000

 Synopsis: iostreams ignore No space left on device condition
 
 Responsible-Changed-From-To: unassigned->pme
 Responsible-Changed-By: pme
 Responsible-Changed-When: Wed Jun  6 16:50:17 2001
 Responsible-Changed-Why:
     I felt like it.
 State-Changed-From-To: open->analyzed
 State-Changed-By: pme
 State-Changed-When: Wed Jun  6 16:50:17 2001
 State-Changed-Why:
     Thank you for your bug report.
     
     Note that "priority: high" is reserved for GCC maintainers
     (please read the bug-reporting instructions).
     
     With the current 3.0 branch, I get
     
         % /tmp/pme/gnatsing/a.out
         0 0 1 0
         0 0 1 0
         %
     
     on a full device.  In any case, I don't believe that
     testing for specific error conditions (no space left on
     device, drive offline, network down, disk spindle on fire,
     etc) is the library's responsibility.  More specifically:
     
     The current default configuration passes I/O to the stdio
     fwrite(3) function; the only thing the C++ library knows
     is what fwrite(3) returns, namely, the bytes successfully
     written.  If something goes wrong (out of space), a short
     count is returned.  The C++ library tests for this
     condition (in xsputn()) and set the failbit accordingly.
     
     If the underlying filesystem doesn't do anything that would
     cause fwrite(3) to return an error, then the C++ library
     has nothing to go on.  The behavior of the OS kernel and
     its filesystem drivers also come into play.
     
     So, I think this is not in our bailiwick, personally, but
     I'm leaving this PR open for others to comment.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2913&database=gcc

Re: libstdc++/2913

[Phil Edwards]

The following reply was made to PR libstdc++/2913; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: Brad Garcia <garsh@home.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2913
Date: Wed, 21 Nov 2001 13:35:12 -0500

 On Wed, Nov 21, 2001 at 03:56:00PM -0000, Brad Garcia wrote:
 >  Basically, we will never catch errors that occur when we attempt
 >  to close a stream (where the close causes a final flush to occur
 >  before actually closing the file).
 
 I have posted a patch that causes the return from fclose() to be checked.
 Still waiting on approval.
 
 pme
 

Re: libstdc++/2913

[Brad Garcia]

The following reply was made to PR libstdc++/2913; it has been noted by GNATS.

From: Brad Garcia <garsh@home.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, donut@azstarnet.com,
        pme@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/2913
Date: Wed, 21 Nov 2001 11:15:45 -0500 (EST)

   http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2913&database=gcc
 
 We've done some testing and determined that the implementation
 of basic_filebuf::_M_really_overflow is ignoring the return value of
 _M_file->sync().  We are seeing sync() return EOF as expected during
 the out-of-space condition, but since this isn't being checked and
 propagated, the badbit is not getting set in basic_ios.
 
 So this is definitely a bug in libstdc++, not in the operating system.
 And it's a pretty severe bug.
 
 Basically, we will never catch errors that occur when we attempt
 to close a stream (where the close causes a final flush to occur
 before actually closing the file).
 
 pme said:
 
     The current default configuration passes I/O to the stdio
     fwrite(3) function; the only thing the C++ library knows
     is what fwrite(3) returns, namely, the bytes successfully
     written.  If something goes wrong (out of space), a short
     count is returned.  The C++ library tests for this
     condition (in xsputn()) and set the failbit accordingly.
     
     If the underlying filesystem doesn't do anything that would
     cause fwrite(3) to return an error, then the C++ library
     has nothing to go on.  The behavior of the OS kernel and
     its filesystem drivers also come into play.
 
 
 
 Brad Garcia
 

Re: libstdc++/2913

[Matthew Mueller]

The following reply was made to PR libstdc++/2913; it has been noted by GNATS.

From: Matthew Mueller <donut@azstarnet.com>
To: pme@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Subject: Re: libstdc++/2913
Date: Sat, 16 Jun 2001 21:29:27 -0700

 I didn't mean to suggest that it should check individual errors, just
 that it is ignoring this (and probably all) errors in a certain case.
 If you compare our results, I think the reason is apparent.  Your test
 returns error on both the write and the file close.  My test with 2.95
 returned error only on close, likely due to buffering issues.  So my
 theory is that in 3.0 the error is not checked when closing the file,
 only on writing it.  Due to buffering, fclose(3) return value must be
 checked for errors too.
 
 -- 
 Matthew Mueller
 donut@azstarnet.com