GCC Bugzilla Bug 35176

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

getrlimit and setrlimit are outside of standard C/C++, they are part of POSIX. 
So it might be best to ask the POSIX guys.

This is just what is expected.

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

POSIX requires that write generates SIGXFSZ if the limit is exceeded (on
systems that support the XSI extensions).

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?

Calling the C stdio functions will result in the same behavior, so the as-if
rule is satisfied.

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.

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 ?