I just found strange thing about sprintf() (c++ library function).
have a look at these two solutions
the only difference between them is that, I used
sprintf(a,"%d%c",n,'\0');
in TLE solution,
in AC solution I replaced above sprintf() with
sprintf(a,"%d",n);
You can also observe that ACed solution took only 0.01s and 2.8MB memory
but TLE solution took around 11.8MB
check here
And one more thing program that gave TLE runs in 0s in IDEONE with extreme input data so is it a bug in CODECHEF itself
Somebody please explain me is this a bug or some considerable unknown operation is happening here.
Thanks in advance.
First of all, the differences in the codes is not with sscanf, but with sprintf. A diff of the code explains:
--- ac.c 2014-05-24 14:31:18.074977661 -0500
+++ tle.c 2014-05-24 14:30:52.270650109 -0500
@@ -4,7 +4,7 @@
string mul(string m, int n){
char a[4];
-sprintf(a,"%d",n);
+sprintf(a,"%d%c",n,'\0');
int l1 = strlen(a);
//printf("len : %d\n",l1);
int l2 = m.length();
Second, by explicitly packing the string with %c and '\0', you are reducing the size of the integer that can be stored in a by 1. You need to check the return of sprintf. man printf:
Upon successful return, these functions return the number of characters printed (not including the trailing '\0' used to end output to strings).
In your case you are most likely writing beyond the end of your a[4] string and are experiencing undefined results. With a[4] you have space for only 999\0. When you explicitly add %c + '\0', you reduce that to 99\0\0. If your number exceeds 99, then sprintf will write beyond the end of the string because you are explicitly packing an additional '\0'. In the original case sprintf(a,"%d",n); 999 can be stored without issue relying on sprintf to append '\0' as a[3].
test with n = 9999, sprintf will still store the number in a, but will return 5 which exceeds the space available a[4], meaning that the behavior of your code is a dice-roll at that point.