<div class="gmail_quote">On Sat, Mar 20, 2010 at 8:04 PM, Matthew Mondor <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net">mm_lists@pulsar-zone.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, 20 Mar 2010 15:32:56 +0100<br>
Juan Jose Garcia-Ripoll <<a href="mailto:juanjose.garciaripoll@googlemail.com">juanjose.garciaripoll@googlemail.com</a>> wrote:<br>
<br>
> A candidate for failure is when you create a file descriptor with one mode<br>
> and try to fdopen() it with a different mode, as in the following tiny<br>
> example:[...]<br>
> Replacing smm_io with smm_input fixes the problem here.<br>
<br>
</div>The following (attached) test case works fine however, using mode 0 or<br>
07777, except for the close(2) syscall since fclose(3) closes the<br>
internal file descriptor (which as necessary could be fixed using<br>
dup(2)/dup2(2) of course).  There the FD is also open O_RDONLY yet the<br>
fdopen(3) and fgets(3) calls work fine with an "rw" FILE...</blockquote></div><div><br></div>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.<div>
<br></div><div>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>
</div>