Re: filebuf::fd()

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Dec 03, 2001 at 03:25:38AM -0500, Phil Edwards wrote:
> On Mon, Dec 03, 2001 at 07:24:30AM +0000, Nathan Myers wrote:
> > > |     1)  for is_open, make it clear that we're comparing pointers.
> > 
> > I would suggest comparing to (FILE*)0 if you think it's important to 
> > clarify what's going on.  NULL is a C-ism and, in C++, is meaningless
> > to the compiler.
> 
> On the contrary, NULL is defined to the magical __null, which g++ knows
> can only be a pointer value.  It's one of the builtin identifier nodes.
> Comparing to 0 doesn't look intuitive to beginners.

Yes, __null is a pointer, but its type is not checked otherwise.
(FILE*)0 is completely clear and unambiguous, and every detail
is checked.  Anybody who doesn't understand what it means will
learn nothing by reading the sources anyway.
 
> > There is no standard requirement nor practical reason for a filebuf 
> > to have a FILE underneath, but it necessarily uses a file descriptor
> > in a POSIX environment.  I don't think we should be documenting an 
> > interface that commits us to an implementation technique we would be 
> > better off freeing ourselves from.
> 
> Here's what really burns me about returning a file descriptor:  the
> library never uses one.  Anywhere.

That's another problem to fix someday.
 
> If a third I/O choice comes along -- some PDA, for example, with one
> of those tiny PCMCIA drives -- which doesn't use type 'int' to 
> represent file handles, /then/ we'll look like idiots for making too 
> many assumptions.

POSIX says it's an int.  That's not an assumption, it's a requirement.
Users running on a non-POSIX platform will need something else equally
non-portable, and will #ifdef it in.  The fd() member should be guarded 
with an #ifdef _USE_THIS_OR_THAT in addition to whatever guards 
extensions.

When you're providing low-level access to underlying apparatus you 
do users no favors in trying to abstract it.  They [I] want a file 
descriptor to make system calls on.  Giving them [me] a FILE* 
amounts to a cruel joke.

> The __basic_file probably won't be FILE* (like in stdio) nor whatever
> funky type gets used in libio, but it /will/ make sense to the 
> programmers using that platform, and they'll know what to do with 
> whatever type we pass back.
> 
> Is it really too hard to write
>     int fd = fileno( (FILE*) a_filebuf.get_underlying_object() );
> in the stdio case, instead of
>     int fd = a_filebuf.fd();
> ?

It's trivial to write that.  But that's not the point.  The problem
is that it commits us to constraining our filebuf to have stdio
implementation and semantics underneath.

The right way to implement this, on a mature target, is for the 
FILE struct to contain or be derived from a filebuf<char>.  In that 
case there's no FILE* to return.
 
Nathan Myers
ncm at cantrip dot org