On Tue, Jan 13, 2009 at 00:16:14 +0100, [email protected] 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
