On Sat, Mar 20, 2010 at 8:04 PM, Matthew Mondor <mm_lists@pulsar-zone.net> wrote:
On Sat, 20 Mar 2010 15:32:56 +0100
Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:

> A candidate for failure is when you create a file descriptor with one mode
> and try to fdopen() it with a different mode, as in the following tiny
> example:[...]
> Replacing smm_io with smm_input fixes the problem here.

The following (attached) test case works fine however, using mode 0 or
07777, except for the close(2) syscall since fclose(3) closes the
internal file descriptor (which as necessary could be fixed using
dup(2)/dup2(2) of course).  There the FD is also open O_RDONLY yet the
fdopen(3) and fgets(3) calls work fine with an "rw" FILE...

The outcome of fdopen() in that case is OS-dependent. OS X definitely complains if you try to "rw" an O_RDONLY file, to the point that the output of fdopen() is -1 and you can not change the buffer nor do I/O. But my point was whether you could test the updated source code and see whether now ecl_make_stream_from_fd() complains with your input values. Otherwise I am going to need some more guidance to find out how you trigger the error.

Juanjo

--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com