GNOME Bugzilla – Bug 756550
gtypes.h: Make G_MININTn literals negative
Last modified: 2016-08-16 23:52:49 UTC
This is more friendly to the GIR scanner; with previous definitions, the constant values end up out of range for their stated integer type.
Created attachment 313238 [details] [review] gtypes.h: Make G_MININTn literals negative
Comment on attachment 313238 [details] [review] gtypes.h: Make G_MININTn literals negative > 6.3.1.3 Signed and unsigned integers > > 1 When a value with integer type is converted to another integer type > other than _Bool, if the value can be represented by the new type, it > is unchanged. > > 2 Otherwise, if the new type is unsigned, the value is converted by > repeatedly adding or subtracting one more than the maximum value that > can be represented in the new type until the value is in the range of > the new type. > > 3 Otherwise, the new type is signed and the value cannot be represented > in it; either the result is implementation-defined or an implementation- > defined signal is raised. So the current code isn't just confusing, it actually depends on undefined behavior. (Funny that neither gcc nor clang warns about this...) The definition of G_MAXUINT64 is pretty special too... that ought to be using G_GUINT64_CONSTANT rather than making assumptions like that (which don't work with two of the possible definitions of G_GINT64_CONSTANT in configure.ac).
Attachment 313238 [details] pushed as 05aafe2 - gtypes.h: Make G_MININTn literals negative
This results in a warning regression on MSVS 2015: warning C4146: unary minus operator applied to unsigned type, result still unsigned Seems like the `0x` prefix implies that the value is unsigned.
Ah no, the base is obviously irrelevant, this is about the value being out of range. Hmm.
This is actually only an issue for G_MININT32. The warning is fixed by rewriting it to: #define G_MININT32 ((gint32) (-0x7fffffff - 1)) This is what Microsoft's limits.h does.
(In reply to Ole André Vadla Ravnås from comment #6) > This is actually only an issue for G_MININT32. The warning is fixed by > rewriting it to: > > #define G_MININT32 ((gint32) (-0x7fffffff - 1)) > > This is what Microsoft's limits.h does. Can this bug be reopened? I can confirm that 05aafe2 breaks compilation with Visual C++ 2013, and that this change fixes it.