Re: [pdf-devel] Missing stream backend error conditions.

[gerel]

 > Date: Mon, 18 May 2009 22:25:18 -0400
 > From: Michael Gold <address@hidden>
 > Content-Disposition: inline
 > 
 > 
 > --TB36FDmn/VVEgNH/
 > Content-Type: text/plain; charset=us-ascii
 > Content-Disposition: inline
 > Content-Transfer-Encoding: quoted-printable
 > 
 > On Mon, May 18, 2009 at 21:14:17 -0300, gerel wrote:
 > =2E..
 > > Sure, it all comes down to one thing:  error !=3D eof !=3D no_read/writte=
 > n data.
 > > I believe the current code was meant to work mainly for memory backends.
 > >=20
 > > So, the set of status code for Stm module read/write operations should be:
 > >       - PDF_OK
 > >       - PDF_EEOF (read)
 > >       - PDF_EAGAIN (read/write)
 > >       - PDF_ENOSPC (write)
 > >       - PDF_EINVOP (read for write mode and viceversa)
 > >       - PDF_ERROR (other error)
 > =2E..
 > 
 > Those are good, but we may need a few more:
 >   - PDF_EBADFILE could be returned if a filter reads invalid data

That kind of error is handled as PDF_ERROR (as read in the doc ref.)

 >   - PDF_EIO (not yet defined) if the backend has some kind of I/O error

It seems ok for future use.

 >   - maybe PDF_EIMPLLIMIT and PDF_ENOMEM if the filters can produce these
 > 

Same as for PDF_EBADFILE, it returns PDF_ERROR right now.

A bad file has nothing to do with memory availability so, we should distinguish
between them.

 > Also, EINTR either has to be handled in the backend (by retrying the
 > operation), or propagated upward.

I guess it should be handled by the backend, so we can keep the API simpler.


regards,

-gerel