After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639558 - Pixbuf new_from_data() vs overload
Pixbuf new_from_data() vs overload
Status: RESOLVED FIXED
Product: gnome-perl
Classification: Bindings
Component: Gtk2
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk2-perl-bugs
gtk2-perl-bugs
Depends on:
Blocks:
 
 
Reported: 2011-01-14 19:50 UTC by Kevin Ryde
Modified: 2011-08-17 22:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch and test case (3.21 KB, patch)
2011-01-14 19:50 UTC, Kevin Ryde
committed Details | Review

Description Kevin Ryde 2011-01-14 19:50:38 UTC
Created attachment 178349 [details] [review]
patch and test case

Is there a reason Gtk2::Gdk::Pixbuf->new_from_data() demands SvPOK of its data input?  I thought it might SvPV to stringize in the usual way.  Doing so would allow overloads and magic to work there the same way as they do elsewhere.

(It normally seems like a bad idea to enquire into the nature of a scalar.  For a string ask for a string and let perl worry how to get it :-)

Possible simplification below, copying out the SvPV data into a malloced block for the pixbuf data area rather than an newSVsv.

(I plan also to check the length of the input, to see the given width*height and rowstride won't overrun the data area.  That would be with or without this change.  Maybe SvPVbytes too if it unmangles any 0x80 to 0xFF wide chars, and/or guards against chars 0x100 up.)
Comment 1 Torsten Schoenfeld 2011-08-08 16:02:40 UTC
(In reply to comment #0)
> Is there a reason Gtk2::Gdk::Pixbuf->new_from_data() demands SvPOK of its data
> input?  I thought it might SvPV to stringize in the usual way.  Doing so would
> allow overloads and magic to work there the same way as they do elsewhere.

Sounds good to me.

> Possible simplification below, copying out the SvPV data into a malloced block
> for the pixbuf data area rather than an newSVsv.

Also good.  But any particular reason you use perl's memory-handling macros?  Nearly all the other code in Glib and Gtk2 uses glib's things (g_new, g_memdup).
Comment 2 Kevin Ryde 2011-08-17 01:39:58 UTC
I can't remember why I thought the perl malloc was a good idea, only maybe to use perl mallocs from within the perl level.  Both die horribly when out of memory if I'm not mistaken, though no doubt in subtly different ways.  Do the perl ones attempt exit/cleanups better?  Otherwise I don't suppose it makes a difference.
Comment 3 Torsten Schoenfeld 2011-08-17 22:13:30 UTC
Yeah, I guess you're right.  I thought that with g_new and friends, there might
be a possibility of some memory pooling happening, but that can also be said
about New and friends.

Patch committed with slight adjustments.  Thanks.