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

[Michael Gold]

On Tue, Jan 13, 2009 at 00:16:14 +0100, address@hidden wrote:
> 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 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:

My plan is for the tokeniser to have a pdf_stm_t object, and just call
read/peek_char without looking at lower-level details like the file or
filesystem interfaces. I'd prefer to keep those details encapsulated.

> 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?

No, I don't believe so. It doesn't matter whether there's an RIA
operation pending -- what we'd need to know is whether we can read the
next byte. Even if the byte ranges covered by RIA requests were known,
we couldn't always determine whether another byte was available since we
could be reading from a filtered stream.

For example, we might have the next 400 bytes of the file, but still
have no data available because we're reading from a compressed object
stream and don't have a full block of data to decompress. This condition
wouldn't be known until you fed the remaining data to the decompression
filter and failed to get output; at this point you're probably in the
middle of a read/peek call, and returning EWOULDBLOCK seems like the
easiest way to handle it.

-- Michael

signature.asc
Description: Digital signature