SUMMARY of Implementing cairo_read_func_t/cairo_write_func_t properly

"Bernhard R. Fischer" <[email protected]>
Newsgroups gmane.comp.lib.cairo
Message-ID <[email protected]>
On 2016-01-05 08:12, Bernhard Fischer wrote:
> On Monday 04 January 2016 18:26:28 Behdad Esfahbod wrote:
>> On 16-01-04 06:24 PM, Bill Spitzak wrote:
>>> On Sun, Jan 3, 2016 at 11:50 PM, Bernhard Fischer <[email protected]
>>>
>>> <mailto:[email protected]>> wrote:
>>>     On Sunday 03 January 2016 14:29:57 Behdad Esfahbod wrote:
>>>     > On 16-01-02 09:34 PM, Bill Spitzak wrote:
>>>     > > On 01/02/2016 01:27 PM, Bernhard Fischer wrote:
>>>     > >> On Saturday 02 January 2016 13:01:39 Bill Spitzak wrote:
>>>     > >>> I think the api has to be changed to return number of bytes
>>>     > >>> read, and a
>>>     > >>> negative number for eof.
>>>     > >> 
>>>     > >> The return value should be the number of bytes read and on eof it
>>>     > >> is
>>>     > >> something between 0 and length. If it is called again at/after
>>>     > >> eof it
>>>     > >> returns 0 again. A negative value (-1) is only returned in case
>>>     > >> of error
>>>     > >> (but not EOF). This is exactly like read(3) behaves.
>>>     > > 
>>>     > > Yes you are correct, I made a typo, I meant to say "error" where I
>>>     > > wrote
>>>     > > "eof". I fully agree with your description.
>>>     > 
>>>     > Given that we cannot change the signature now, I suggest we hack it
>>>     > up to
>>>     > interpret negative numbers returned from the callback to be
>>>     > interpreted as a short read; the absolute value of the returned
>>>     > negative number is the number of bytes read.
>>>     > 
>>>     > Cairo itself won't need to be updated, but clients should be
>>>     > encouraged to
>>>     > implement the new behaviour.
>>>     > 
>>>     > b
>>>     
>>>     I agree, that is a backwards compatible solution.
>>>
>>> I think you need to make negative number mean "it was this short". Ie if a
>>> request to read 10 bytes only reads 8, it returns -2.
>>>
>>> The reason is so that reading the entire block still returns
>>> CAIRO_STATUS_SUCCESS.
>> That works as well.  I was thinking, negative number returned only if not a
>> full read.
> 
> 
> I have a new idea to stay backwards compatible:
> The read function shall return the negative number of bytes which have NOT 
> been read, i.e. - (length - bytes_read).
> 
> This is that a full read will return 0 which is CAIRO_STATUS_SUCCESS.
> Truncated reads return something between -1 and -length.
> And on error, of course CAIRO_READ_ERROR is returned.
> 
> 
> Bernhard
> 


The conclusion of this discussion was to slightly adapt the meaning of
the return value of the read_func_t as follows:


The read function shall return the negative number of bytes which have
NOT been read, i.e. - (length - bytes_read).
This is that a full read will return 0 which is CAIRO_STATUS_SUCCESS.
Truncated reads return something between -1 and -length. On error,
CAIRO_STATUS_READ_ERROR is returned (which is a positive value).



If there is the consent of the core devs we should adapt the docs.

I'll have a look at cairo_image_surface_create_from_png_stream() if
there is a change necessary.

Bernhard

-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.