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 561692 - gcc warning with printf("%llu\n", my_uint64_variable) on 64-bit system
gcc warning with printf("%llu\n", my_uint64_variable) on 64-bit system
Status: RESOLVED DUPLICATE of bug 618404
Product: vala
Classification: Core
Component: general
0.5.x
Other All
: Low minor
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2008-11-20 15:46 UTC by Martin Olsson
Modified: 2010-07-29 23:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample showing that %llu incorrectly compiles (use this for trying out repro steps) (403 bytes, application/x-compressed-tar)
2008-11-20 15:47 UTC, Martin Olsson
Details

Description Martin Olsson 2008-11-20 15:46:09 UTC
Please describe the problem:
It seems that valac mistakenly aborts compilation of:
printf("%lu\n", my_uint64_variable)

At least on my 64-bit system the glib configure script defines (in glibconfig.h):
typedef unsigned long guint64;

Steps to reproduce:
1. download the reduced vala sample code attached to this bug report
2. "make run"
3. open the generated main.c and change %llu into %lu
4. "make ccode"
5. gcc now compiles it without warnings

The problem is that if I modify the vala code to say %lu instead of %llu then valac will _incorrectly_ fail the compilation.

Note: during "make run" for the sample as it's uploaded, gcc _correctly_ prints a warning because the attached sample code has a mismatch between the format specifier used and the variable (i.e. uint64 should _NOT_ use %llu when used in conjuction with printf)

I think %lu is the correct one but valac fails when that one is used.

Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Martin Olsson 2008-11-20 15:47:07 UTC
Created attachment 123119 [details]
sample showing that %llu incorrectly compiles (use this for trying out repro steps)
Comment 2 Martin Olsson 2008-11-20 15:52:29 UTC
The compile error that valac (incorrectly?) prints when %lu is used in the vala code looks like this:

main.vala:4.37-4.43: error: Argument 2: Cannot convert from `uint64' to `ulong'
	stdout.printf ("big_num == %lu\n", big_num);
	                                   ^^^^^^^
Compilation failed: 1 error(s), 0 warning(s)
make: *** [all] Error 1
Comment 3 Jürg Billeter 2008-11-20 15:59:58 UTC
%lu will only work on 64-bit systems. On 32-bit systems it's incorrect as unsigned long is 32-bit and the application might crash. That's the reason why Vala reports an error, it's not portable code.

%llu should work fine on 32-bit and 64-bit systems, can you explain what issue you have with %llu?
Comment 4 Martin Olsson 2008-11-20 17:07:04 UTC
gcc prints a "mismatched type" warning for %llu

mnemo@kingfish:~/testcode/vala_stuff/warning_guint64_vs_llu_int$ make
main.c: In function ‘_main’:
main.c:14: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘guint64’
mnemo@kingfish:~/testcode/vala_stuff/warning_guint64_vs_llu_int$ cat main.vala
public int main (string[] args)
{
	uint64 big_num = 42;
	stdout.printf ("big_num == %llu\n", big_num);

	return 0;
}
mnemo@kingfish:~/testcode/vala_stuff/warning_guint64_vs_llu_int$ 

------

Another way to silence the warning is to keep %llu but also emit a cast from guint64 to "long long unsigned int" like this:
fprintf (stdout, "big_num == %llu\n", (long long unsigned int)big_num);

Assuming that cast is safe; I think that would be a good solution.
Comment 5 geert jordaens 2010-05-22 17:48:49 UTC
Duplicate #618404  - Uses 32-bit x86 formatters for printing numeric values using printf, etc.
Comment 6 Luca Bruno 2010-07-29 23:12:36 UTC
Thanks for the bug report.
Marking as duplicate of 618404 since there's a patch there.

*** This bug has been marked as a duplicate of bug 618404 ***