GNOME Bugzilla – Bug 722039
Rank values for gchar and gint8 are incorrect
Last modified: 2018-05-22 15:03:02 UTC
gchar definition specifies a rank of '2', when it can contain values between 0 and 127. gint8 definition has a rank of '1', when it can contain values between -128 and 127. The rank values should be swapped, because a gchar can be stored in a gint8, but a gint8 can't be stored in a gchar.
Sorry, why gchar is between 0 and 127? A gchar is like a gint8 in C.
(In reply to comment #1) > Sorry, why gchar is between 0 and 127? A gchar is like a gint8 in C. It's defined in vapi as such. And gchar is either signed or unsigned so the range is either -128 to 127 or 0 to 255[1] - and char in C is different type then either signed char or unsigned char IIRC, in the end I don't think gchar should be a number (I guess some reasons why it have to be that way). [1] At least - it can be larger according to C standards.
As commented by Maciej, the definition of gchar in the VAPI file is [SimpleType] [GIR (name = "gint8")] [CCode (cname = "gchar", cprefix = "g_ascii_", cheader_filename = "glib.h", type_id = "G_TYPE_CHAR", marshaller_type_name = "CHAR", get_value_function = "g_value_get_char", set_value_function = "g_value_set_ [IntegerType (rank = 2, min = 0, max = 127)] public struct char { [...] The range is defined in the VAPI to be between 0 and 127. Of course, if it is changed to -128 to 127 it could, then, be paired with the same rank than gint8. I suppose that the reason for using a range of 0-127 is because an ASCII code can't be negative, and also it is the range for the pure, 7-bit, original ASCII code.
(In reply to comment #3) > As commented by Maciej, the definition of gchar in the VAPI file is > > [SimpleType] > [GIR (name = "gint8")] > [CCode (cname = "gchar", cprefix = "g_ascii_", cheader_filename = "glib.h", > type_id = "G_TYPE_CHAR", marshaller_type_name = "CHAR", get_value_function = > "g_value_get_char", set_value_function = "g_value_set_ > [IntegerType (rank = 2, min = 0, max = 127)] > public struct char { > [...] > > The range is defined in the VAPI to be between 0 and 127. Of course, if it is > changed to -128 to 127 it could, then, be paired with the same rank than gint8. > But it isn't guaranteed to contain this range on all platform. The gchar is either 'similar to' guint8 or gint8 (it's basicly inherited strangeness from C). > I suppose that the reason for using a range of 0-127 is because an ASCII code > can't be negative, and also it is the range for the pure, 7-bit, original ASCII > code. I don't think it can be assumed that gchar stores ASCII. It's likely to store some sort of 1 byte code unit dependent on platform and locale. On Linux it will usually be a utf-8 code unit although it can be say ISO-8859 code point - both are rather in range of 0-255 then 0-127 although compiler might treat it as -128-127. In general I don't think there is any reason why most programmers (i.e. except those who program Pango etc.) should care about encoding as they belong to 'complicated' category and dealing with them is like dealing with time - you get a weird cases (as missing days[1], summer time etc. in time or what's a character in encoding[2]) so better to deal with them in higher-level wrappers. [1] http://en.wikipedia.org/wiki/Gregorian_calendar [2] A lot of problems with encodings are mentioned here: http://www.utf8everywhere.org/
All I'm doing is speculating about the reasons that could have driven the original author of the VAPI file to set a range of 0-127 for gchar (there is also guchar, which has the right 0-255 range). I agree in that the logical range should be (-128,127).
Created attachment 266079 [details] [review] Changes the gchar range to -128,+127 After Maciej's comments, I suppose that the fix should be this: change the range to -128,+127, and the rank to 1 (the same than gint8). Of course, another possibility is to keep the rank as 2, allowing to automatically cast a gint8 to a gchar, but not a gchar into a gint8.
(In reply to comment #5) > All I'm doing is speculating about the reasons that could have driven the > original author of the VAPI file to set a range of 0-127 for gchar (there is > also guchar, which has the right 0-255 range). I agree in that the logical > range should be (-128,127). I guess it is because there is no guarantee that on all platforms -1 is in range (or 128 for that matter). According to C specification the char is either signed or unsigned type. If it signed it has range [-128, 127], so it does not include 128, if it is unsigned it has range [0, 256], so it does not include -1 (excluding exotic types of machines - yay for 40 years of accumulating quirks). For that reason patch is not exactly correct for all platforms/compilers (it might be even that MSVC uses different char then gcc). I believe the attributes are just for Vala compiler to check if constant can be stored in variable - and -1 and 128 are not guaranteed to be in range - not for any information for the user. So the char is put into hierarchy were gint8/guint8 is while it's guaranteed range is lower (but it's real range is as large as one of those). But I'm speculating at this point as well.
Can you please explain what problem did you have in using char to need this patch applied?
No problem really, just found that mistake in the VAPI when creating a list with the ranks of the basic types. That's why I marked it as "trivial".
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/425.