[cairo] 'cairo_restore()' doesn't restore context in error case

[Vladimir Vukicevic]

On Feb 19, 2008, at 2:02 PM, Carl Worth wrote:

> On Tue, 19 Feb 2008 23:00:15 +0200, "Iosif Haidu" wrote:
>> On Tue, Feb 19, 2008 at 3:32 AM, Behdad Esfahbod  
>> <behdad at behdad.org> wrote:
>>> On Sat, 2008-02-16 at 00:50 +0200, Iosif Haidu wrote:
>>>>> it. For an unknown reason sometime some windows gdi functions
>>>>> (CreateCompatibleDC(), BitBlt() and other) fail to execute with  
>>>>> error
>>>>> code 6 and 8. In this situation the cairo function responsible  
>>>>> with
>>>>> that windows gdi function call will set the error status to
>>>>> CAIRO_STATUS_NO_MEMORY and the 'cairo_restore()' will not  
>>>>> restore the
>>>>> cairo context. I have noticed that cairo context actually has  
>>>>> not been
>>>>> damaged by the failure of the windows gdi function, yet the  
>>>>> context is
>>>>> not restored.
>>
>>>> As I said on the bug, the this is a bug that should be fixed.  If  
>>>> the
>>>> failing gdi functions are not fatal, this should be handled in
>>>> cairo.
>
> Definitely. If there are non-fatal things happening in the underlying
> system, then cairo is broken by considering it an error. Even if the
> errors are fatal, cairo is broken by calling them NO_MEMORY if that's
> not the case, (maybe we need CAIRO_STATUS_GDI_MYSTIC_PROBLEM or
> something?).

Maybe, though I've never seen the original errors.  I'm not a fan of  
NO_MEMORY, though; but there just isn't a good way of returning  
backend-specific error codes.  A while back I think I made a proposal  
to turn the error code bits into a system where backends can return  
per-backend error codes... either via something like  
CAIRO_BACKEND_ERROR_BASE+n where that specific error would then be  
only valid for the specific surface backend in use, or to turn all  
error codes into just returning static pointer values, like we do for  
user data keys now.  Both would require a bit of machinery to implement.

      - Vlad