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 59254 - g{u}int{8|16|32|64} gparam/gvalue support
g{u}int{8|16|32|64} gparam/gvalue support
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gobject
1.3.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2001-08-20 13:49 UTC by mathieu lacage
Modified: 2011-02-18 15:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to fix the bug (20.36 KB, patch)
2001-08-20 13:50 UTC, mathieu lacage
none Details | Review
add g{u}quad type to glib (23.20 KB, patch)
2001-09-15 22:21 UTC, Joshua N Pritikin
none Details | Review

Description mathieu lacage 2001-08-20 13:49:13 UTC
gobject lacks gparam/gvalue support for g{u}int{8|16|32|64}.
Comment 1 mathieu lacage 2001-08-20 13:50:13 UTC
Created attachment 919 [details] [review]
patch to fix the bug
Comment 2 Owen Taylor 2001-08-25 02:47:03 UTC
http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00524.html

Has an explanation of why 8/16/32 aren't really needed. And I'd
agree that if we can keep the set of types down, we are doing better.

64-bit support would probably be nice, but at this point, I think
we need to put that off until 2.2


Comment 3 Joshua N Pritikin 2001-09-15 04:49:53 UTC
Why can't g{u}int64 be added before 2.0?

gstreamer uses off_t for byte offsets which need to be
available via GParam.  Natually off_t is 64bit, given
the size of DVDs.

i don't care about the other types, only 64-bit ints.
Comment 4 Erik Walthinsen 2001-09-15 04:52:59 UTC
gint64 support in gobject params is critical for GStreamer, among
other   
things.  Timestamps must be 64-bit values because they are expressed
in   
nanoseconds (so audio sample times are accurate).  Without 64-bit
support
in glib, GStreamer will not be able to function.  Period.

The patch attached to this bug may go to far in creating all the
smaller  
values, because I agree with the mail linked in, that's what the
ranges   
are for.  But because the vast majority of the world's machines are
still
32 bit, 64-bit must be supported as an 'unusual' type.  For machines
that
are already 64 bit, it may be compiled to be the usual 'int' type,
because
it would be.  But it must exist in 2.0, or any project that relies on
passing around large values will not be able to function without the
end  
user applying a 3rd party patch to glib.
Comment 5 Joshua N Pritikin 2001-09-15 17:19:42 UTC
None of the other type names contain numbers so instead
of g{u}int64, it is probably more consistant to use the
names quad and uquad.
Comment 6 Joshua N Pritikin 2001-09-15 22:21:22 UTC
Created attachment 5610 [details] [review]
add g{u}quad type to glib
Comment 7 Havoc Pennington 2001-09-15 22:32:37 UTC
Quad??? that is awful. ;-)

INT64 - clear, concise, everyone knows what it is.
Comment 8 Owen Taylor 2001-09-19 21:49:43 UTC
Under discussion on gtk-devel-list.
Comment 9 xavier.bestel 2001-09-26 18:59:27 UTC
Sure, adding 64bits types to params wouldn't break binary
compatibility (GtkArg is alread 64bits wide).
Plus, it's required to work with gstreamer. Would be great to have
this before 2.0.
Comment 10 Owen Taylor 2001-10-03 20:14:52 UTC
Wed Oct  3 16:02:24 2001  Owen Taylor  <otaylor@redhat.com>

	* glib-genmarshal.c gparamspecs.[ch] gvalue.h 
        gobject/gvaluetypes.[ch]: Add support for G_TYPE_INT64
	and storing it in GValue (Patch from Mathieu Lacage, #59254.)