[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: File descriptor indeed not always available? (was: Re: How do I pass
From: |
Olaf Till |
Subject: |
Re: File descriptor indeed not always available? (was: Re: How do I pass a file pointer to my octfile?) |
Date: |
Fri, 24 Sep 2010 01:00:20 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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