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 161520 - passing LONG_MAX to gdk_property_get
passing LONG_MAX to gdk_property_get
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.5.x
Other Linux
: Normal normal
: Small fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: 161512
 
 
Reported: 2004-12-17 04:10 UTC by Ian Wienand
Modified: 2005-08-27 04:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Update documentation and correct incorrect use of sizeof(long) (1.93 KB, patch)
2004-12-17 04:10 UTC, Ian Wienand
none Details | Review
ahhh, bytes not bits :) (1.93 KB, patch)
2004-12-17 04:23 UTC, Ian Wienand
rejected Details | Review
Clamp G_LONGMAX value, update documentation to reflect 64 bit strangeness (3.95 KB, patch)
2004-12-24 01:47 UTC, Ian Wienand
none Details | Review

Description Ian Wienand 2004-12-17 04:10:00 UTC
gdk_property_get uses sizeof(long) to calculate the returned bytes. 
XGetWindowProperty is actually returning the number of 32 bit elements; not the
number of 'long' elements so on machines with long == 8 bytes the length is
incorrect.

The documentation is also incorrect.  

This has resulted in an overflow bug described at
http://bugzilla.gnome.org/show_bug.cgi?id=161512

I've attached a patch with suggested changes.
Comment 1 Ian Wienand 2004-12-17 04:10:42 UTC
Created attachment 34925 [details] [review]
Update documentation and correct incorrect use of sizeof(long)
Comment 2 Ian Wienand 2004-12-17 04:23:54 UTC
Created attachment 34926 [details] [review]
ahhh, bytes not bits :)
Comment 3 Owen Taylor 2004-12-17 14:56:26 UTC
64-bit was implemented very strangely in Xlib ... 32 bit properties
are converted into arrays of longs and GTK+ follows this convention.

The overflow issue there may be a real problem... the 
(length + 3) / 4 rounding will produce a negative value for LONGMAX
for both 32 and 64-bit values. The code probably needs to clamp
the input value to avoid such overflow.
Comment 4 Ian Wienand 2004-12-24 01:47:58 UTC
Created attachment 35179 [details] [review]
Clamp G_LONGMAX value, update documentation to reflect 64 bit strangeness

This patch clamps the value if it will overflow to be negative.
Comment 5 Matthias Clasen 2005-05-18 14:48:47 UTC
2005-05-18  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkproperty-x11.c (gdk_property_get): Warn if
	length overflows.  (#161520, Ian Wienand)
Comment 6 Owen Taylor 2005-08-26 20:10:33 UTC
I don't think this was the right fix. G_MAXLONG has an obvious meaning
"as much as you can get", and should be fixed to pass the biggest acceptable
protocol value to X.
Comment 7 Matthias Clasen 2005-08-27 04:25:48 UTC
2005-08-27  Matthias Clasen  <mclasen@redhat.com>

	* gdk/x11/gdkproperty-x11.c (gdk_property_get): Don't warn
	when G_MAXLONG is passed as length.