CAIRO_STATUS_SUCCESS becomes CAIRO_INT_STATUS_NO_MEMORY ?

[Konstantin KABASSANOV]

> -----Message d'origine-----
> De : cairo <cairo-bounces at cairographics.org> De la part de Mihai Moldovan
> Envoyé : jeudi 20 mars 2025 23:05
> À : cairo at cairographics.org
> Objet : Re: CAIRO_STATUS_SUCCESS becomes
> CAIRO_INT_STATUS_NO_MEMORY ?
> 
> * On 3/20/25 18:26, Konstantin KABASSANOV wrote:
> > Even if _cairo_tor_scan_converter_add_polygon returns the only value
> > it could return (CAIRO_STATUS_SUCCESS), the composite_polygon status
> > variable gets CAIRO_INT_STATUS_NO_MEMORY…
> >
> > Could it be a somehow wrong mapping between cairo_status_t and
> > cairo_int_status_t types values? It seems that the numerical value in
> > memory corresponding to the status variable changes to 0x01 and if I
> > print the value casted to both types, I can see
> > CAIRO_INT_STATUS_NO_MEMORY in GDB…
> 
> I've only quickly looked at the code, but no.
> 
> Both structs are enums and match up for the first values.
> 
> 
> Are you absolutely sure that you're looking at the correct function?
> mono_scan_converter_allocate_edges() can and does return
> CAIRO_STATUS_NO_MEMORY for instance.
> 
> 
> Are you sure that your compiler is not optimizing out stuff, that leaves you
> bewildered, even though the end result is probably sane? (try -O0
> -fno-omit-frame-pointer -g3 -ggdb3 -gdwarf-4)
> 
> 
> 
> Mihai

Well, you were right about the optimization (in addition we must take care of different debugger caches). In the meantime I sent you an email that (fortunately) never arrived.
It seems that my issue is related to a matrix->y0 translation that is bigger than PIXMAN_MAX_INT ( 116422 > 32767 ). It happens in the _pixman_image_for_recording function, after the second cairo_matrix_invert in the done: jump...

Konstantin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8409 bytes
Desc: not available
URL: <https://lists.cairographics.org/archives/cairo/attachments/20250324/ebea01d3/attachment.bin>