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

[John W. Eaton]

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.  Does that work
correctly on Windows sytems?

| 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.

Thanks,

jwe