*** Can/should streambuf::sputbackc(char) assume that the putback area
is writable?

I.e. is the following a valid implementation:

int streambuf::sputbackc(char c)
{
    if (gptr() <= eback()) return pbackfail(c);
    gbump(-1);
    *gptr() = c;
    return zapeof(c);
}

Problem: what if the get area is a read-only string?
Or a copy-on-write file buffer?

How about:

int streambuf::sputbackc(char c)
{
    if (gptr() <= eback()) return pbackfail(c);
    gbump(-1);
    return zapeof(c);
}

Problem: What if we want to remember putback'ed characters
in a buffer? Solution: Make sure pbackfail is always called
in those cases.

Or the paranoid solution:

int streambuf::sputbackc(char c)
{
    if (gptr() <= eback()) return pbackfail(c);
    gbump(-1);
    if (*gptr() != c)
	*gptr() = c;
    return zapeof(c);
}

The assumptions should be specified by the standard.

*** The 2.1 Library manual page 3-19 section "Files" says:
"A subtle point is that closing a file stream (either explicitly or
implicitly in the destructor) will close the underlying file
descriptor if it was opened with a filename, but not
if it was supplied with attach."

I assume the [io]fstream::attach(fd) rule also applies to
the [io]fstream::[io]fstream(int fd) constructors?

How about filebufs? Will "delete (new filebuf(0))"
close the underlying file descriptor? What about
"(new filebuf(0))->close()"?