public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/35176]  New: SIGXFSZ in filebuf
@ 2008-02-13  2:43 sebor at roguewave dot com
  2008-02-13  3:16 ` [Bug libstdc++/35176] " pinskia at gcc dot gnu dot org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: sebor at roguewave dot com @ 2008-02-13  2:43 UTC (permalink / raw)
  To: gcc-bugs

When compiled with gcc 4.1.2 the program below dies with SIGXFSZ on Linux.
I don't think the standard allows filebuf to report errors using signals
(since it describes file I/O in terms of C stdio), nor does a signal seem
desirable in C++.

$ cat u.cpp && g++ u.cpp && ./a.out || echo $?
#include <fstream>
#include <sys/resource.h>

int main ()
{
    rlimit rl;
    getrlimit (RLIMIT_FSIZE, &rl);

    rl.rlim_cur = 32;
    setrlimit (RLIMIT_FSIZE, &rl);

    std::filebuf fb;
    if (0 == fb.open ("testfile.text", std::ios::out))
        return -1;

    for (rlim_t i = 0; i != rl.rlim_cur + 1; ++i)
        fb.sputc ('*');

}
File size limit exceeded
153


-- 
           Summary: SIGXFSZ in filebuf
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebor at roguewave dot com
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
@ 2008-02-13  3:16 ` pinskia at gcc dot gnu dot org
  2008-02-13 14:33 ` rguenth at gcc dot gnu dot org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-02-13  3:16 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-13 03:15 -------
getrlimit and setrlimit are outside of standard C/C++, they are part of POSIX. 
So it might be best to ask the POSIX guys.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
  2008-02-13  3:16 ` [Bug libstdc++/35176] " pinskia at gcc dot gnu dot org
@ 2008-02-13 14:33 ` rguenth at gcc dot gnu dot org
  2008-02-13 15:47 ` sebor at roguewave dot com
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-13 14:33 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-13 14:33 -------
This is just what is expected.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
  2008-02-13  3:16 ` [Bug libstdc++/35176] " pinskia at gcc dot gnu dot org
  2008-02-13 14:33 ` rguenth at gcc dot gnu dot org
@ 2008-02-13 15:47 ` sebor at roguewave dot com
  2008-02-13 16:09 ` schwab at suse dot de
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: sebor at roguewave dot com @ 2008-02-13 15:47 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from sebor at roguewave dot com  2008-02-13 15:46 -------
I used setrlimit() only to emulate low disk space conditions. The same
"problem"
occurs in a pure C++ program (i.e., one that makes no POSIX or other non-C++
calls) when it really does run out of disk space.

So again, since C++ iostreams is specified in terms of C stdio, I don't see
how this is allowed. Can you explain on what basis you think this is conforming
behavior? Does stdio generate SIGXFSZ? (I haven't checked any real
implementations but I didn't see anything about it in C or POSIX).


-- 

sebor at roguewave dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
                   ` (2 preceding siblings ...)
  2008-02-13 15:47 ` sebor at roguewave dot com
@ 2008-02-13 16:09 ` schwab at suse dot de
  2008-02-13 16:37 ` sebor at roguewave dot com
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: schwab at suse dot de @ 2008-02-13 16:09 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from schwab at suse dot de  2008-02-13 16:08 -------
POSIX requires that write generates SIGXFSZ if the limit is exceeded (on
systems that support the XSI extensions).


-- 

schwab at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
                   ` (3 preceding siblings ...)
  2008-02-13 16:09 ` schwab at suse dot de
@ 2008-02-13 16:37 ` sebor at roguewave dot com
  2008-02-13 16:57 ` rguenth at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: sebor at roguewave dot com @ 2008-02-13 16:37 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]



------- Comment #5 from sebor at roguewave dot com  2008-02-13 16:37 -------
I understand that POSIX requires the signal but I'm not sure I see what that
has to do with filebuf. C++ specifies that filebuf member functions behave
"as if" by calling the C stdio functions.

See 27.8.1, p2:

  In this subclause, the type name FILE refers to the type FILE declared in
  <cstdio>.
  A File provides an external source/sink stream whose underlaid character
  type is char (byte).

and 27.8.1.4, the description of filebuf::open():

  It then opens a file, if possible, whose name is the NTBS s (“as if” by
  calling std::fopen(s, modstr))

There is no mention in the C++ standard of filebuf calling POSIX write(),
and while I agree that doing so makes sense (our own implementation does
it), strictly speaking it doesn't seem to be allowed by the "as if" clause.
In addition, I don't think exposing C++ programs to signals as a result is
desirable. So it seems that a conforming implementation of filebuf that
chooses to use POSIX I/O needs to suspend signals while making POSIX calls
that might lead to signals.

If you disagree and think the C++ standard permits this behavior could you
point to the relevant wording?


-- 

sebor at roguewave dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
                   ` (4 preceding siblings ...)
  2008-02-13 16:37 ` sebor at roguewave dot com
@ 2008-02-13 16:57 ` rguenth at gcc dot gnu dot org
  2008-02-13 18:16 ` sebor at roguewave dot com
  2008-02-13 19:06 ` pinskia at gcc dot gnu dot org
  7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-13 16:57 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from rguenth at gcc dot gnu dot org  2008-02-13 16:56 -------
Calling the C stdio functions will result in the same behavior, so the as-if
rule is satisfied.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
                   ` (5 preceding siblings ...)
  2008-02-13 16:57 ` rguenth at gcc dot gnu dot org
@ 2008-02-13 18:16 ` sebor at roguewave dot com
  2008-02-13 19:06 ` pinskia at gcc dot gnu dot org
  7 siblings, 0 replies; 9+ messages in thread
From: sebor at roguewave dot com @ 2008-02-13 18:16 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from sebor at roguewave dot com  2008-02-13 18:15 -------
I see I should have checked the actual stdio behavior instead of relying on
the standard. Recent Linux and Solaris both do, in fact, generate SIGXFSZ out
of C stdio. AIX 5.3 does not, and neither does HP-UX 11.23, although HP-UX
11.33 does, suggesting a bug fix.

Do you happen to have a pointer to the text in the POSIX (or C) spec that
requires (or allows) this behavior of stdio?

Also, even if it is allowed, I still don't think it's desirable. I'm curious
what other libstdc++ maintainers think. Benjamin, Paolo? I'll probably raise
this on c++std-lib@accu.org.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug libstdc++/35176] SIGXFSZ in filebuf
  2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
                   ` (6 preceding siblings ...)
  2008-02-13 18:16 ` sebor at roguewave dot com
@ 2008-02-13 19:06 ` pinskia at gcc dot gnu dot org
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-02-13 19:06 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from pinskia at gcc dot gnu dot org  2008-02-13 19:06 -------
One issue is we have two standards here.  The POSIX one and the C++ one.  Now
getrlimit/SIGXFSZ signal is a POSIX issue while using filebuf is a C++ one. 
Now does POSIX talk about filebuf ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-02-13 19:06 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-13  2:43 [Bug libstdc++/35176] New: SIGXFSZ in filebuf sebor at roguewave dot com
2008-02-13  3:16 ` [Bug libstdc++/35176] " pinskia at gcc dot gnu dot org
2008-02-13 14:33 ` rguenth at gcc dot gnu dot org
2008-02-13 15:47 ` sebor at roguewave dot com
2008-02-13 16:09 ` schwab at suse dot de
2008-02-13 16:37 ` sebor at roguewave dot com
2008-02-13 16:57 ` rguenth at gcc dot gnu dot org
2008-02-13 18:16 ` sebor at roguewave dot com
2008-02-13 19:06 ` pinskia at gcc dot gnu dot org

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