[pdf-devel] Re: Handling errors in pdf_stm_read_char/peer_char

[jemarch]

Hi Michael.

   > In the meanwhile, did you try to make the tokeniser to use a reading
   > stream? Would be a nice try out of the get_char and peek_char
   > operations in the streams.

   I have this working now, but I don't see any way for those functions to
   indicate errors.

Right. A filter may fail, or the filesystem backend could return some
other errors.

   There's a special return value PDF_EOF, but the tokeniser should
   differentiate between errors and EOF, and should also be able to
   recover from some errors. For example, we might get EWOULDBLOCK
   when reading a PDF over HTTP and want to continue parsing when more
   data is available.

For PDF_EWOULDBLOCK, please note that the filesystem implementation
has support for read-in-advance capabilities (see gnupdf.info > Base
Layer > The Filesystem Module > The File Interface:: > Read in
Advance).

The default filesystem (used when fsys == NULL in the filesystem
interface calls) is the disk filesystem that is being worked by
Aleks. The disk filesystem is not implementing read-in-advance
capabilities, since disks are fast, but eventual html or webdav
filesystem implementations will support these capabilities. Note that
a filesystem supporting RIA will likely implement an in-disk cache
that will be feeded by an asynchronous thread (or several threads).

The lexer will have access to both the file interface and the
filesystem interface, and will open a reading stream configured to
operate in a pdf_fsys_file_t object. You can check if there is a RIA
operation for a given open file with:

 -- Function: pdf_bool_t pdf_fsys_file_has_ria (pdf_fsys_file_t FILE)
     Determine whether the filesystem is performing some RIA operation
     for the given open file.

     Note that it is up to the underlying filesystem to honour the
     operation. If the filesystem does not implement RIA capabilities
     then this function always return `PDF_FALSE'.

Maybe we should expand the API so you can ask a given filesystem
implementation if it is supporting RIA at all.

What do you think? Would the API described in gnupdf.info > Base Layer
> The Filesystem Module allow the lexer to address the PDF_EWOULDBLOCK
issue without getting an explicit PDF_EWOULDBLOCK from the pdf_stm_*
calls?

   I think redefining the functions as
     pdf_status_t
     pdf_stm_{read,peek}_char (pdf_stm_t stm,
                               pdf_char_t *ch)
   would be the best way to report errors, since it makes the usage
   obvious. pdf_stm_read and pdf_stm_write would need similar changes.

   Comments?

I agree. We would be also removing the PDF_EOF special value, so the
posterior cast to pdf_char_t would not be needed. I will commit a
patch for this within the next hours.

Thanks.