Re: Implementing cairo_read_func_t/cairo_write_func_t properly

On Friday 01 January 2016 14:35:59 Behdad Esfahbod wrote:
> On 16-01-01 01:01 PM, Bernhard Fischer wrote:
> > On Friday 01 January 2016 12:14:03 Behdad Esfahbod wrote:
> >> On 16-01-01 09:32 AM, Bernhard Fischer wrote:
> >>> On Thursday 31 December 2015 09:54:39 Lawrence D'Oliveiro wrote:
> >>>>> On Wed, 30 Dec 2015 15:27:13 +0100, Bernhard Fischer wrote:
> >>>>>>> when I would return STATUS_READ_ERROR, then the calling function
> >>>>>>> cannot detect how many bytes then actually have been read except in
> >>>>>>> the case that I read 1 byte after the other.
> >>>>> 
> >>>>> Does it matter? In any case, the file is clearly corrupted and the
> >>>>> image decoding has failed.
> >>>>> 
> >>>>> At least, that is my conclusion...
> >>> 
> >>> Yes, it matters!
> >>> cairo_..._stream() are stream reading functions. This is that it does
> >>> not
> >>> know in advance how many bytes are available in the file.
> >>> 
> >>> The read_func_t is called with a buffer of a programmer-chosen length
> >>> (from
> >>> within cairo_..._stream()), e.g. 10k. But if the file has just 9k,
> >>> obviously only 9k are read. Unfortunately, the programmer has no way to
> >>> find that out.
> >> 
> >> I agree this could be designed better...
> > 
> > I know that this is now getting deep into fundamental design issues.
> > 
> > I'd suggest a new prototype for that purpose. See the following file line
> > numbers 17 - 32. I experimentally implemented it into my jpeg stream
> > reader
> > function (optionally chosen by cpp macro):
> > 
> > https://github.com/rahra/cairo_jpg/blob/master/src/cairo_jpg.h
> 
> You can have both at the same time.
> 
> b


Yes, but from a user's point of view (somebody who will use this API) it may 
be confusing to have two functions whose functionality is equal.

Bernhard


-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo