@vijju123 Is there a difference? both long long and long long int are same AFAIK
long long is the same type as long long int, just as long is the same as long int.
Using cout to print the answer instead of printf gives correct answer for that test case
working 
great… thanks for sharing…
Still, C-style I/O is a legitimate part of C++, and it is not supposed to misbehave. And a mere presence of a header changing program behavior does not seem right.
Unfortunately, we cannot debug the issue to the full extent. It seems that the issue is related to the output buffer, therefore some fiddling with flushing helps. For a complete analysis we also need to know how CodeChef judge is organized in regards to input/output streams.
I was not able to replicate the situation on my local environment - gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609. The problem is only reproducible when running on CodeChef judge.
What’s observable - CodeChef judge is definitely more robust with cin/cout IO.
Although fflush(stdout) does seem to make it work, I would not say for sure buffering is the problem, since even after disabling buffering with setbuf(stdout, NULL) the behavior does not change (works with fflush but not without).
I’m using printf() and scanf() with bits/stdc++.h since a long time and this kind of problem never occured. Many other people do it as well
As long as you are using iostream with printf() and scanf() you will get WA for that test case
Looks like including header causes initialization of the standard C++ streams and their synchronization with the standard C streams. Adding ios_base::sync_with_stdio(false) corrects the issue.
Respect @gorre_morre
Thanks for debugging…
You really found correct bug…
Btw can you explain why fflush worked ?
Giving you 10 extra reputation for this…
Seeee, it turned out to be undefined behavior after all XD.
@l_returns - For undefined behavior, you really cannot say. Even adding a int aabcdef=1; might have worked and given AC for that case. Perhaps it all depends on what value was in memory accessed out of bounds? I guess that part had a good value 
1 Like
But it should be undefined forever isn’t it… like random function… If it really depends on memory value…
You predicted it correctly…@vijju123 
Why it is defined as AC for one library and defined as WA for other one…
Why it is defined for one library and not defined for other one...
Its not so. Thing is, anything can happen in undefined behavior. Even for same library, things like print statements, new varaibles etc can change stuff. It all depends on what compiler does/make your code while compiling it. It applies some optimizations, does some reordering etc to fasten execution.
Okay thanks… I think I understood what u meant…
@l_returns Didn’t really use anything fancy. Simply went through the code and added some asserts to check the indexing (something I’m very fond of doing even in my own code). At first I thought that maybe there was a problem with the factorial but none of those asserts triggered, ruling out any obvious problems with the factorial. Then I saw the strangely written while-loop, and it was pretty clear what was the problem.
1 Like