Getting a file descriptor or a file number) for an fstream (Was: Accessing the underlying file descriptor in fstream)

[Theodore Papadopoulo]

OK, the title of the mail was confusing. I changed it.

>| I do not have a recent C standard handy (my K&R book is an old pre 89 
>| book) so may be I will get it wrong but I seem to remember that at least one 
>| of the two variants of open or fopen is standardized in C. 

>That is not the question under discussion.

Agreed, but the C standard has some implications (mostly to have a 
portable solution) also.
I went ahead and looked at it and it seems that only FILE* are standardized.

>| ... Delivering 
>| an extension of the library that allows interoperation between 
>| streams and the C library or the system is a matter of quality of implementation 
>| IMHO. I can see three possible variants:

>Well, it is not a QoI.
>It is a matter of extension with a far reaching impact on the whole
>implementation.  Maybe you might want to study other implementai

Call it as you prefer...

>| 3) Return whatever is used in the stream library and let the user 
>| deal with the result. This is certainly the easiest thing, but there 
>| are portability issues. stream ARE now based on FILE* AFAIK but 
>| this is only temporary, right ?

>It IS temporary.

That is exactly why I believe that the variant 3) I proposed is
a poor choice.

>You might want to take a look at popular IOStream implementations
>around, such as those designed by Matt Austern, Dietmar et al to have
>an idea of what the issues are.

The problem is not so how is implemented iostream but can we convert 
what is used to a FILE* or an int (to keep only my 1) and 2) 
variants). Now, I have had a look at some of iostream implementations.
For all what I know, there are three cases right now:

1) fstreams are implemented on open/close.

This is the SGI's team choice AFAICT. Returning a file number is easy (for 
the SGI lib it is the member _M_file_id). Returning a FILE* is not 
very difficult on many systems using fdopen provided the opening mode 
is stored somewhere. Portability problems may arise in this case
since the function is not in the C standard, but it is POSIX.1 so 
that most Unix systems will be OK (I do not know MS well enought but 
I'm sure there is a similar function). 

2) fstreams are implemented over fopen,fclose.

This is what is TEMPORARILY used in libstdc++-v3. FILE* are easy.
Returning file numbers is usually easy since the function/macro 
fileno usually returns the file number associated with the FILE*.
However, it seems that this function is not in the C standard nor in 
the POSIX.1 one so that portability is more questionnable.

3) fstreams are implemented over libio.

This is both what was used/will be used in libstdc++-v3.
This is certainly the case I know the least.
However, as far as my understanding goes, from the information I got 
from the gcc lists, libio is designed to be a common underlying level 
to help a smooth integration between FILE and int based ios. I assume 
that getting a FILE* from libio structure is feasible, since this is 
what is certainly done in functions like fopen...

>Certainly, something has to be done, but FILE* doesn't seem to be
>popular in reasonable IOStream implementations.

The problem is not there. 
I totally agree with the fact that iostream is not implemented over FILE*
and that returning a FILE* should not constrain the way libio is 
implemented.

On the other hand, whatever is used to do fstream should be 
convertible (any libio specialist listening ?) to a FILE*.

As I said in my previous mail providing an int is OK for me, but I 
feel that this is prone to portability troubles. FILE* are an ANSI C 
standard, so if possible it is the best choice. Returning int (which 
after all is SVr4, SVID, POSIX X/OPEN and BSD 4.3) would be my second 
choice. But again, frankly among the two, I do not really care.
FILE* just seem a better choice standard-wise IMHO.

Just a final note to state that flushing problems, concurrency 
problems and so on should be left out for now. These are definitely 
important problems but in the absence of any prior or any standard 
whatever we will do with this respect today will have to change if 
something standard emerges.

Thus, if it is possible to implement the feature (and I think it is), 
let's keep it as simple as possible, make no promise and clearly 
state that it is an extension (eventually, activate it 
only with a special flag). Last, if full portability cannot be 
achieved keep it conditionnal to the system, althought I'd prefer not 
going that direction.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------


-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.2 06/23/2000

iD8DBQE6io2OIzTj8qrxOU4RAvTZAJ9RNdWZ7/W7ntp/aURx42nhWclKVACdG9zO
kzdKQ71BchlMeUak0FqBp9E=
=DLE/
-----END PGP SIGNATURE-----