GNOME Bugzilla – Bug 623774
Don't include machine-independent integral types in the typelib
Last modified: 2015-02-07 16:50:22 UTC
Previously we had both e.g. GI_TYPE_TAG_LONG and GI_TYPE_TAG_INT64, but in fact the typelib is already machine-specific, so it makes sense to just encode this as a fixed type. The .gir remains abstract. We also remove size_t from the typelib; one would never want to treat it differently than an integer. time_t is removed as well; while bindings like gjs had special handling to turn it into e.g. a JS Date object, I don't think we should encourage people to use these POSIX types in their API. Use GTimeVal or the like instead. Because the typelib is now really machine-specific, we need to remove the -expected.tgirs from git. (We could potentially add a check which wasn't just a literal diff later)
Created attachment 165431 [details] [review] Don't include machine-independent integral types in the typelib
Created attachment 165432 [details] [review] Don't include machine-independent integral types in the typelib A two-line update which fixes the sign on gsize/gssize
<jdahlin> walters: looks quite good, will break the format I'll update the patch to bump the typelib format. As I guess this is the first actual change to libgirepository, we should bump the soname too. I'll prep a separate patch for this. <jdahlin> walters: glist/gslist could be merged into one type, and ghash be renamed to hash Lists can't be merged; we're relying on the tag to differentiate them now. I guess we could strip the 'G' prefix but it feels a little gratuitous. As it is now for example gjs could be patched to conditionally compile against g-i 0.6 relatively easily; if we renamed the list types it'd be harder.
Created attachment 165502 [details] [review] [girepository] Bump shared library version, typelib version
Created attachment 165503 [details] [review] Don't include machine-independent integral types in the typelib Previously we had both e.g. GI_TYPE_TAG_LONG and GI_TYPE_TAG_INT64, but in fact the typelib is already machine-specific, so it makes sense to just encode this as a fixed type. The .gir remains abstract. We also remove size_t from the typelib; one would never want to treat it differently than an integer. time_t is removed as well; while bindings like gjs had special handling to turn it into e.g. a JS Date object, I don't think we should encourage people to use these POSIX types in their API. Use GTimeVal or the like instead. Because the typelib is now really machine-specific, we need to remove the -expected.tgirs from git. (We could potentially add a check which wasn't just a literal diff later)
The bug/commit summary seems backwards to me; "long" is a machine-dependent type, and "int64" is machine-independent, and you're getting rid of "long". So shouldn't it be "Don't include machine-dependent integral types in the typelib", not "machine-INdependent"?
Review of attachment 165503 [details] [review]: This looks really good. It needs to be announced when we make the next release somehow. With instructions how this affects current users. ::: girepository/girparser.c @@ +387,3 @@ + switch (integer_aliases[i].size) + { + case 1: Use enums instead of magic numbers here @@ +389,3 @@ + case 1: + if (integer_aliases[i].is_signed) + return &basic_types[3]; Ditto ::: girepository/gitypelib.c @@ +925,3 @@ SimpleTypeBlob *type; + g_assert (G_N_ELEMENTS (value_size) == GI_TYPE_TAG_ERROR + 1); You can add a N_TAG_ELEMENTS to the end of the public enum to avoid this
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]