Re: Why fixing 9533 doesn't fix 7744: revealed!

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20030306040248 dot GA27802 at tofu dot dreamhost dot com> Nathan Myers writes:

> What was the reason that you chose a one-character buffer over making
> it entirely unbuffered?  They seem equivalent, but having three modes
> seems unnecessarily complicated.

Speaking for myself only, we might have hacked it without considering
some other options.  Sorry.  Would disabling buffering in libc with
setbuf(0, 0) have been enough to fully address the interactive cases?
(Ah, I think if the abstraction error was concurrently fixed, this
approach probably works.)

> Yes, this the path forward: make the native mode fast and clean, and 
> make the hack mode (just barely) work.  I like the idea of two
> entirely different objects, one a hack job on stdio and the other
> purely POSIX-native, and sync_with_stdio(false) plugs the latter
> in in place of the former.

OK, we are of like minds in how to get a possible major speed up on
many POSIX platforms.

> <rant>
> One thing to get away from is this idea that it's OK for C++ to be a
> second-class citizen, dependent on C for its low-level access.  C++
> is not a bag on C, it's a whole other language.  It has to be link-
> compatible with C, but besides that it should stand alone.  The 
> libstdc++.so should talk directly to the OS.  Non-POSIX users who want 
> the library to perform well for them may supply patches making 
> similarly low-level access for their platforms.  We shouldn't
> (e.g.) introduce thread-unsafety just to avoid the need for low-level
> access, or introduce undue complexity in trying to perform well where
> we don't have low-level access.

Your view makes sense to me.  However, for the sake of argument only,
it has been stated that libstdc++-v3 shall use the system's libc
wherever possible (that view has had merit as well given the goals of
the FSF).  Also, the standard C++ library includes libc by reference.
It explicitly states how e.g. C++ and C IO must interleave to comply
with the standard.  Would you advocate that `-lstdc++ -lc' (note
order) should pick up C IO from libstdc++.so?  As an aside, someone
filed a PR against libstdc++ just today regarding global namespace
leakage from system headers when they only included e.g. <vector>.  I
think one could make a claim that programs that included only headers
dictated by the C++ standard <[a-z]*> *and* <c[a-z]*> should have zero
such leakage.  I think the root cause is the same (layering atop libc
and the platform's system headers).  However the claim is easier said
than done.  Multiple efforts have been conducted over the years to
properly shadow system headers and move decls into std::, etc.

> Our C++ locale code should read the same files as the C library does,
> instead of calling C library functions and trying to patch up after.  
> For non Glibc systems, POSIX provides tools to extract the files to 
> a standard format; the library installer can use these to generate
> corresponding files for our library's use, in Glibc's format.  That 
> way the code to read the files may be common to all POSIX platforms.  
> Then, users of non-POSIX platforms can send utilities to convert their 
> own locale files' formats (or make do with just the "C" locale).

I think these words are properly directed at me and my crazy ideas
from last week RE hacking up generic locale support.  (FYI, I came to
my senses and will install something that forces generic locale
support as-is to report attempts to create unsupported locales.)  One
issue, even on POSIX platforms, the libc might not handle multiple
locales.  glibc does this by having parallel entry points for many IO
calls.  But this observation plays into your observation about
attempting to reuse libc thus making libstdc++ a second-class citizen
on the platform.

> On many platforms we can achieve better integration with stdio by 
> deriving streambuf from FILE and making the setg/setp/eback/gptr/
> egptr/pptr/epptr family of functions refer to the same (inherited)
> struct members as do getc and putc do, and make underflow and 
> overflow use the same file descriptor member.  There's just not 
> so much variation in stdio implementations.

Perhaps I am reading this final point too literally.  In all
seriousness, do you know a trick to allow this in general?  E.g. one
BSD looks like this:

typedef struct __sFILE {
  [...standard says this is opaque...]
} FILE;

How do I derive anything against FILE?  I mean, sure:

class foo_streambuf : FILE {};

is legal code; but (a) in general, FILE* may never be safely converted
to foo_streambuf*; and (b) to peer in the opaqueness seems dangerous
unless you really know the implementations well.

Regards,
Loren