GNOME Bugzilla – Bug 663054
64bit enums and flags
Last modified: 2013-06-13 11:37:46 UTC
GEnumValue and GFlagsValue rely on gint and guint respectively, and therefore they are not able to hold 64bit enumerations. 64-bit enums is probably a pretty rare case, but 64-bit flags is not; needing more than 32 bitflags can be quite common. Therefore, it would be great to have 64bit enums and flags in GLib/GObject, e.g. 'GEnum64Value' and 'GFlags64Value', with their own GParamSpecs, their own to/from GValue, and such. I can spend some time preparing a patch for this, but better get comments on whether it's a good idea or not.
I think this'll be a bit more involved, i.e. you most probably need to add two new fundamental types for this, as TYPE_ENUM/FLAGS can be hardcoded to fit into gint in many locations (also user code). Then again, *adding* fundamental types hasn't been done since GType was initially written, there may be some significant fallout in third party code, i.e. all code that currently does things like switch (G_TYPE_FUNDAMENTAL (id)) will need adaption. Are 64bit enums worth the hassle? Depending on your use case, you might be able to get away with 2 32bit flags fields as well. I'll leave the call up to the current GLib maintainers, as I most probably won't have the time to review this in details, but I'm around for the occasional hand if someone really wants to go through the excercise of adding a new fundamental type. ;)
> Are 64bit enums worth the hassle? Depending on your use case, you might be able > to get away with 2 32bit flags fields as well. In the use case I have, I shouldn't have many problems to split the flags into 2 32bit sets, but it may end up being not very clean. My impression is that if the language allows having 64bit values in enums, GLib sooner or later should also allow it. > I'll leave the call up to the > current GLib maintainers, as I most probably won't have the time to review this > in details, but I'm around for the occasional hand if someone really wants to > go through the excercise of adding a new fundamental type. ;) Thanks :-)
While 686662 is newer, it has a slightly different design that I think we'd need to take. *** This bug has been marked as a duplicate of bug 686662 ***