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 688829 - Variable overflow in utils.c test on 32-bit machine
Variable overflow in utils.c test on 32-bit machine
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: build
2.34.x
Other Mac OS
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-11-21 18:37 UTC by Daniel Macks
Modified: 2012-12-19 19:28 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
G_GINT64_CONSTANT fixes the constant type (1.13 KB, patch)
2012-11-22 03:20 UTC, Daniel Macks 		accepted-commit_now Details | Review
G_GUINT64_CONSTANT fixes the constant type (1.13 KB, patch)
2012-11-29 15:35 UTC, Daniel Macks 		accepted-commit_now Details | Review

Description Daniel Macks 2012-11-21 18:37:36 UTC 
Building glib-2.34.2 on OS X 10.6 in 64-bit mode, glib/tests/utils.c compiles cleanly. In 32-bit mode:

gcc -arch i386 -DHAVE_CONFIG_H -I. -I../.. -g -I../.. -I../../glib -I../../glib -I../.. -DG_LOG_DOMAIN=\"GLib\" -DSRCDIR=\""."\" -DG_DISABLE_CAST_CHECKS  -I/sw/include   -Os -Wall -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c
utils.c: In function 'test_swap':
utils.c:228: warning: integer constant is too large for 'long' type
utils.c:229: warning: integer constant is too large for 'long' type

That region of code is:

  a64 = 0xaaaaaaaabbbbbbbb;
  b64 = 0xbbbbbbbbaaaaaaaa;

Tracing back, those variables are guint64, which is unsigned long long, which has a size of 8 bytes, which is the same as on 64-bit. I have no idea why it's overflowing.
Comment 1 Daniel Macks 2012-11-21 18:55:02 UTC 
Looks like (apple's) gcc doesn't recognize that the type is 64-bit until after it has freaked out that the constant is larger than a default type of long. Builds cleanly with clang. Also builds cleanly with gcc if I make the assignments:

  a64 = 0xaaaaaaaabbbbbbbbLL;
  b64 = 0xbbbbbbbbaaaaaaaaLL;

to predeclare their sizes. That doesn't seem too portable, since the guint64 type is an autoconf result? And interestingly, the result is still the full long-long (not truncated to long) in the actual variable value. Feel free to close this as "silly gcc is silly" or something.
Comment 2 Colin Walters 2012-11-21 18:58:15 UTC 
This is what the G_GINT64_CONSTANT() macro exists for.
Comment 3 Colin Walters 2012-11-21 23:52:59 UTC 
Daniel, want to do a patch?
Comment 4 Daniel Macks 2012-11-22 03:20:58 UTC 
Created attachment 229615 [details] [review]
G_GINT64_CONSTANT fixes the constant type

Thanks for finding that macro. Works for me!
Comment 5 Colin Walters 2012-11-22 09:27:12 UTC 
Review of attachment 229615 [details] [review]:

Looks good, thanks for the excellent commit message.
Comment 6 Christian Persch 2012-11-22 14:25:55 UTC 
a64 and b64 are guint64, so should use G_GUINT64_CONSTANT instead of G_GINT64_CONSTANT.
Comment 7 Colin Walters 2012-11-23 13:01:27 UTC 
(In reply to comment #6)
> a64 and b64 are guint64, so should use G_GUINT64_CONSTANT instead of
> G_GINT64_CONSTANT.

Good catch; Christian, do you want to just push a patch?
Comment 8 Daniel Macks 2012-11-29 15:35:41 UTC 
Created attachment 230204 [details] [review]
G_GUINT64_CONSTANT fixes the constant type
Comment 9 Colin Walters 2012-11-29 15:52:12 UTC 
Review of attachment 230204 [details] [review]:

Looks right.