[Ecls-list] si:file-stream-fd && gray:stream-file-descriptor

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Sun Mar 21 09:15:29 UTC 2010


On Sun, Mar 21, 2010 at 12:45 AM, Matthew Mondor
<mm_lists at pulsar-zone.net>wrote:

> On Sat, 20 Mar 2010 19:35:46 -0400
> Matthew Mondor <mm_lists at pulsar-zone.net> wrote:
>
> > I think that this is different, for the stream now works fine, and an
> > error is signalled properly when fdopen(2) fails...  So here fdopen(2)
> > succeeded, the stream was created and I could read-char and read-line
> > from it, but the functions which now crash are the ones to query the
> > underlaying file descriptor afterwards (si:file-stream-fd,
> > gray:stream-file-descriptor).
>
> When I tested si:file-stream-fd the intention was to verify if it works
> so that I could possibly implement an alternative function which
> instead of using fileno(3) on the file handle could possibly report the
> fh error/eof state.  Because unfortunately, FORCE-OUTPUT will not
> report at all why it stopped flushing if an error occurred, so I should
> either be able to use fflush(3) from C and/or ferror(3)/feof(3), but
> for that I need the pointer to the underlaying stdio FILE stream.


FORCE-OUTPUT (on streams that are not file streams) does report errors. It
looks at the output of fflush() and when this is EOF, it calls the following
function, which inspects the error condition and _always_ reports an error
unless the error was an interrupt, in which case it retries.

static int
restartable_io_error(cl_object strm)
{
cl_env_ptr the_env = ecl_process_env();
volatile int old_errno = errno;
/* ecl_disable_interrupts(); ** done by caller */
maybe_clearerr(strm);
ecl_enable_interrupts_env(the_env);
if (old_errno == EINTR) {
return 1;
} else {
FElibc_error("Read or write operation to stream ~S signaled an error.",
     1, strm);
return 0;
}
}


-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100321/c1f798bd/attachment.html>


More information about the ecl-devel mailing list