Can anyone tell why I am getting c=1 b=0 as the output.
I am using the MinGW that comes the latest version of windows if it helps
Code:#include <stdio.h>
int
main(void)
{
unsigned long long c=1,b=23;
printf("c=%llu b=%llu\n",c,b);
return 0;
}
Printable View
Can anyone tell why I am getting c=1 b=0 as the output.
I am using the MinGW that comes the latest version of windows if it helps
Code:#include <stdio.h>
int
main(void)
{
unsigned long long c=1,b=23;
printf("c=%llu b=%llu\n",c,b);
return 0;
}
i am getting
c=1 b=23
using gcc 3.2.3 on linux
Strangely enough, I am getting the output c=1 b=0
c=1
b=23
with this code
Code:#include <stdio.h>
int
main(void)
{
unsigned long long c=1,b=23;
printf("c=%llu b=%llu\n",c,b);
printf("c=%llu\n",c);
printf("b=%llu\n",b);
return 0;
}
Thanks, that means MinGW is broken. Its damn crazy!!!!Quote:
Originally Posted by viaxd
I meant MinGW that comes with the lastest version of bloodshed.Quote:
Originally Posted by pinko_liberal
> I meant MinGW that comes with the lastest version of bloodshed.
If you do
gcc --version
what do you get?
unsigned long long c=1,b=23;
printf( "%d %d\n", sizeof(c), sizeof(b) );
What do you get?
> unsigned long long c=1,b=23;
> printf("c=%llu b=%llu\n",c,b);
If you compile with
gcc -S prog.c
what do you get in prog.s ?
Compare with calling a function which expects two unsigned long long parameters
void foo ( unsigned long long p1, unsigned long long p2 );
foo( c, b );
Does this fix anything (since printf is a variadic function, and arguments have default promotions)
unsigned long long c=1,b=23;
printf("c=%llu b=%llu\n",(unsigned long long)c, (unsigned long long)b );
gcc.exe (GCC) 3.2 (mingw special 20020817-1)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Code:.file "junk.c"
.def ___main; .scl 2; .type 32; .endef
.text
LC0:
.ascii "c=%llu b=%llu\12\0"
.align 2
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
andl $-16, %esp
movl $0, %eax
movl %eax, -20(%ebp)
movl -20(%ebp), %eax
call __alloca
call ___main
movl $1, -8(%ebp)
movl $0, -4(%ebp)
movl $23, -16(%ebp)
movl $0, -12(%ebp)
subl $12, %esp
pushl -12(%ebp)
pushl -16(%ebp)
pushl -4(%ebp)
pushl -8(%ebp)
pushl $LC0
call _printf
addl $32, %esp
movl $0, %eax
leave
ret
.def _printf; .scl 2; .type 32; .endef
I did cast the results to unsigned long long in an attempt to make it work, it didn't help.Quote:
Originally Posted by Salem
sizeof's are coming to be 8.
Well on the face of it, the compiler is generating the right code for storing and passing unsigned long long values.
So perhaps your library implementation of printf isn't up to scratch.
In short, MSVCRT, which MinGW uses, does not understand "%llu" and interprets it as "%lu". Therefore, you are printing the two halves of the first long long you pass to printf(). You can use "%I64d" and "%I64u" to print signed and unsigned long longs respectively.Quote:
http://groups.google.com/groups?selm...ay.alphanet.ch
"%llu", c'est valable pour les compilateurs et bibliothèques (souvent Unix)
du temps intermédiaire, entre ~1994 et la compatibilité C99 (~2001).
Attention: il ne suffit pas d'un compilateur qui comprend long long: par
exemple, GNU C avec Mingw va rater lamentablement avec la version "normale"
de MSVCRT.DLL, parce que le code de Microsoft ne "comprend" pas "%llu" (je
crois qu'il considère le deuxième l redondant).
Avec une bibliothèque de Microsoft (ou équivalent), et en particulier
MSVCRT.DLL, la solution est "%I64d"
Edit: Found the MinGW page on the issue:
http://www.mingw.org/MinGWiki/index.php/long%20long
thanks! That explains it.Quote:
Originally Posted by anonytmouse