Re: filebuf::fd()

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

On Mon, Dec 03, 2001 at 07:53:32AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> 
> | Anyhow, by popular-and-IMHO-slightly-misguided demand, here's a way for
> | filebuf's to return an underlying file descriptor, for the currently
> | default --enable-cstdio=stdio case.  I did not investigate the libio
> | case.
> | 
> | Also some cleanups:
> |     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.
 
> |     2)  for the testcase file, when our non-standard signature was
> |         changed, the comment was not.  Also <cassert> is included
> |         in the hooks header.
> | 
> | Opinions?
> 
> Recent discussions on the LWG list make me nervous about adding
> extensions, but hey we have to deal with some users requests.

I agree that this is an important extension.  Ideally we'd like for 
users to get a warning if they call it when --pedantic is turned on.
 
> I discussed the issue with Theo two weeks ago.  I think returning a
> FILE* would be self-contained in terms of semantics.  That is, isntead
> of retuning an int (the file descriptor), have a member function --
> say FILE_pointer() -- return a FILE*.  That scheme is extensible to
> libio.
> | +      int 
> | +      fd();
> 
> Replace this with
> 
> +   #ifdef _GLIBCPP_USE_EXTENSIONS
> +      FILE*
> +      FILE_pointer();
> +   #endif

I strongly object to this.  

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.

Nathan Myers
ncm at cantrip dot org