Re: File descriptor indeed not always available? (was: Re: How do I pass a file pointer to my octfile?)

[Olaf Till]

On Thu, Sep 23, 2010 at 02:52:20PM -0400, John W. Eaton wrote:
> On 23-Sep-2010, Olaf Till wrote:
> 
> | On Wed, Sep 22, 2010 at 08:37:59PM -0400, John W. Eaton wrote:
> | > So you can convert a double precision file ID value to an
> | > octave_stream object (assuming there is an open stream that
> | > corresponds to that file ID).  From that, you can convert it to a
> | > pointer to a std::ostream (or std::istream) object.  There is no
> | > direct conversion from that to a C FILE pointer. -- the C++
> | > std::{i,o,io}stream objects might not actually be based directly on C
> | > FILE pointers.  For example, if you open a stream with
> | > 
> | >   fid = fopen ("foo.gz", "wz");
> | > 
> | > you are using zlib functions via a std::ostream object that wraps a
> | > gzFile object, and that doesn't provide a way to get at the underlying
> | > file descriptor or a FILE pointer.
> | 
> | I was not aware of this. Of corse there is the problem that Octaves
> | file IDs are supposed to be identical to the corresponding file
> | descriptors of the system.
> 
> Yes, they are supposed to be the same.
> 
> | But I see that in the latest sources
> | do_stream_open() in file-io.cc now uses gzdopen() instead of gzopen()
> | and passes the file descriptor to octave_zstdiostream::create.
> 
> Right, but that is not the way things work in 3.2.4.  But if we can
> ensure that the file ID in Octave is always the same as the system
> file descriptor number, then presumably, you could just extract the
> integer and use an fdopen to get a FILE pointer.

Yes. But since Octave already uses a FILE pointer, you have two FILE
pointers for the same file descriptor then ...

>  Does that work
> correctly on Windows sytems?

I don't know.

> 
> | At the
> | moment, c_zfile_ptr_buf::file_number() in c-file-ptr-stream.h still
> | returns -1 and
> | 
> | fopen ("foo.gz", "wz")
> | 
> | will return -1 in current Octave.
> | 
> | But surely you are just about to change this?
> 
> No, I missed that, but yes, I will see about fixing it.  Should we
> maybe just remove the file_number function from the stream buffer?
> That info is now handled by the corresponding stream classes.  Or
> should the file descriptor number be stored in the stream buffer class
> with the stream classes forwarding to that?  I think the simpler thing
> is the first option.

Sounds reasonable (the first option), but I wouldn't trust myself to
give advice here.

I must admit that, having seen file_number() in c_zfile_ptr_buf, I
didn't notice that file_number() was also already in the z stream
class; and I infered only from c_zfile_ptr_buf::file_number() that
Octaves

fopen ("foo.gz", "wz")

should still return -1, not by testing (can not run autogen.sh with
current sources at the moment).

Olaf