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

[jemarch]

   First, please note that most of your comments are for already
   existing code, so we should ignore my previous patch on this
   discussion.

Nonsense. Actually most of the issues are for code that is broken only
after the application of your patch, so it is better to not ignore it.

    > If pdf_stm_filter_apply returned PDF_EEOF, pdf_buffer_eob_p should be
    > true, which makes that final check redundant (assuming the other changes
    > I've suggested are made).
    > 

   Sure, it all comes down to one thing: error != eof !=
   no_read/written data.

It all comes down to a quite different thing: your patch is broken.

The current operation of the code is correct given that the backends
are signaling EOF (or disk full) by returning a number of read/written
bytes are less that the number of bytes requested to read/write.

You changed the mode of operation of the backends without even
understanding what was going on in the pdf-stm-* code, and now you are
blaming on perfectly correct code.

   If everyone agrees, I'll work on these issues and send a patch for
   the Stm module.

Ok, but note:

- As pointed out by Michael, the new mode of operation of the backends
  should return EOF only if there are no more bits to read. That would
  simplify a lot the code reading/writing data from/to the backends.

- The rest of the pdf-stm-* code should be adapted to use the new
  interfaces. In particular expressions like (read_bytes <
  filter->in->size) would not be useful anymore. They certainly are
  with the current semantics.

- Regarding the usage of PDF_EEOF in pdf_stm_write, I agree in that
  the value returned by pdf_stm_write should be PDF_ENOSPC, so please
  change it, _BUT_ note that internally the filters are still
  returning PDF_EEOF, since we are reading data from the filters to
  write the output in the stream cache.

- In pdf_stm_flush, the condition (written_bytes != cache_size) would
  become invalid changing the semantics of the backend. This function
  should also return PDF_ENOSPC instead of PDF_EEOF.

- I agree in your suggested list of return values plus PDF_EBADFILE
  and PDF_EIO. To internally manage EINTR seems also ok.

-- 
Jose E. Marchesi
address@hidden

GNU Project
http://www.gnu.org