> Date: Mon, 18 May 2009 22:25:18 -0400 > From: Michael Gold <[email protected]> > 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
