Hello
could someone please explain this odd behavior of a printf() funtion:
Thank you.Code:printf("=%lu =%lu\n", 11111111111, 11111111111); // Output: =2521176519 =2
Hello
could someone please explain this odd behavior of a printf() funtion:
Thank you.Code:printf("=%lu =%lu\n", 11111111111, 11111111111); // Output: =2521176519 =2
http://c-faq.com/stdio/printftypes.html
Try 11111111111UL
Don't know exactly what you mean. If you mean
orCode:printf("=%u =%u\n", 11111111111UL, 11111111111UL);
well neither work.Code:printf("=%lu =%lu\n", 11111111111, 11111111111);
Compiler won't promote type for variadic function like printf.
Thus passing 1233423 means it's just integer for printf. You need to explicitly say the type (either cast or suffix will do for numbers).
E.g
printf("%f \n", 3 ); // won't work pass int. printf expects double.
You need to be consistent!!!!
Try
printf("=%lu =%lu\n", 11111111111UL, 11111111111UL);
Basic C program help
I think this kind of question is quite common.
Last edited by Bayint Naung; 05-24-2011 at 06:58 AM.
Those constants are too big, even for unsigned long.
Try
Of course, you need a real C99 library to be able to deal with this properly.Code:$ gcc -Wall bar.c $ ./a.out =11111111111 =11111111111 $ cat bar.c #include<stdio.h> int main ( ) { printf("=%llu =%llu\n", 11111111111ULL, 11111111111ULL); return 0; }
If you're stuck with some fossil compiler, or are crippled by the MS runtime library that all the MinGW ports rely upon, you're pretty much stuck.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
This does not work.Code:printf("=%lu =%lu\n", 11111111111UL, 11111111111UL);
But this:
works like a charm, even if I input something like:Code:printf("=%llu =%llu\n", 11111111111ULL, 11111111111ULL);
The second number is correct, which is really my issue, I don't have the problem with printing BIG ARSE :P numbers, my problem was that the first number obviously somehow truncated the second one, and that was my real problem. But this works like a fairy tale.Code:printf("=%llu =%llu\n", 111111111111111111111111111111111111111111111ULL, 11111111111ULL);
BTW can anybody explain, why and how this works.
Thanks.
EDIT: I'm using Pelles C
It works because in PellesC unsigned long long is a 64 bit integer... thus ULL and %llu will accept values up to 64 bits...
Thus you have a range from 0 to 18,446,744,073,709,551,614
You can look all this up in your Pelles C help file ...
Open Poide click Help -> Contents ->C99 language reference->Declarations and types->Storage of basic types.
( A) Pelles C is probably the best documented compiler available B) why don't people ever look in help files on their own?)
It's probably a lot clearer to #include <stdint.h> and specify ... uint64_t ... for your variables.
However; your second one with that monster row of 1s should not work even there... If you have to do anything that produces numbers that big you should be working with one of the "bignum" libraries. (Google is your friend)
Last edited by CommonTater; 05-24-2011 at 07:45 AM.
As I said, I don't care about printing large numbers and getting to see the right values, my problem was, when I at first said:
And as you can see the second number got ruined because obviously the first one wrote over it. And that was my problem, but now withCode:printf("=%lu =%lu\n", 11111111111, 11111111111); // Output: =2521176519 =2it leaves the second number alone.Code:%llu
Well I may now enjoy some relaxation
Thanks for all your help guys.
EDIT: Since I am new here, is there any way to mark this thread as "SOLVED" ?
Last edited by juvan; 05-24-2011 at 07:52 AM.
No, that's not what happened... you provided values that caused errors, the result is undefined. That means printf() displayed garbage. nothing was over-written or ruined. ... again READ THE HELP FILE... it's all there.
You are using a compiler that comes with a 1.2mb help file... do you think it might be helpful to actually read it?
Here's a little trick most people miss... put your text cursor on any keyword or library function call... Press F1... Oh my!
If you go to the Pelles C forums you can download a copy of the Windows SDK that will integrate into Pelles C and provide you documentation on basic Windows API calls with F1 as well...
Last edited by CommonTater; 05-24-2011 at 07:58 AM.
A) Yes it really is B) It's hard to look if you don't know what you're looking for.
In the HELP FILE: long long, unsigned long long | 8 bytes | 8 bytes | [3.00] 8 bytes
This was the only thing on the page that had any relevance with my problem, and I myself couldn't have figured out anything from that alone.
Could you please tell me where all of this is said, cuz in the help files alone I see no sign of it.
I think the problem is that you think there's something to figure out. If you lie to printf (by passing in arguments that don't match the format), it will not print things that you want to see. When the things you pass are of different sizes then what you tell printf, then it will get out of alignment.
I was searching with no success, would you perhaps have a link?If you go to the Pelles C forums you can download a copy of the Windows SDK that will integrate into Pelles C and provide you documentation on basic Windows API calls with F1 as well...
What you can't figure out how big a number fits into 8 bytes? Any simple calculator will tell you that... 8 bytes x 8 bits = 64 bits .. 2^64 =
In fact the number I gave you above came from exactly that calculation in windows standard calc.exe application, which I added to my PellesC tools menu for convenience...
Anyway... put your typing cursor on printf and press F1 ... notice that in the resulting brief page fprintf is a link... click the link and VOILA.
Really ... juvan... Since the day you installed Pelles C all this information has been right there for you to explore. WHY WOULD YOU IGNORE IT???
Nice of you to help, but now you're just patronizing. So let's just end the discussion.
HF.