It was just a simple question. A compiled code can obviously give wrong answers but I don't see how this code snippet could have caused variables to increase on their own.
Since you didn't post actual code, neither can we. Seriously, are you expecting us to reverse engineer exactly the code you had written, and then debug it?
There's nothing obviously wrong with the
outline of your code. However, an
outline of code and the
actual code are two different things.
The code no longer exists; it was used for debugging; it look just about like this:
Code:
char *a ;
int *i, j
a = (char *) calloc(12, sizeof (char);
if(strcmp(a,"b"))
printf(" %d, %d\n", *i, j)
As given, your code is missing a semicolon after j is declared. This will not compile.
As given, your code is missing the closing paren of calloc(). This will not compile.
As given, your code is missing the semicolon after the printf. No one can predict what will happen as a result. It could compile perfectly, depending on what comes after it. It could also not compile at all.
As given, your code will always execute the printf() statement. This happens because the 'a' variable points to an empty C string (a newly calloc'ed block, after you fix the other bugs), and that will always compare unequal to the literal "b": i.e. strcmp() will always return a non-zero value. Whether it succeeds at the printf() depends on what i points to; it might crash or print unexpected values.
If it's not obvious, the reason we ask to see actual code is because tiny differences can have huge effects.
You might not think anything of it, but the compiler certainly does. You have to learn to look at code and think like the compiler does.
Consider your previously unparenthesized macro definitions. That could have been solved a lot sooner if you'd posted the actual #define, instead of paraphrasing it by writing "It's defined to 5400". It
wasn't defined to 5400; it was defined to the product of 3 other macro expansions, none of which were parenthesized.
Also consider that a single misplaced comma can cause apparently separate statements to become one (because comma is an operator, not just a parameter separator in function calls).
It is also possible for certain arrangements of missing close-parens to be interpreted and compiled without error. The result isn't anything at all like what was intended.
If you can't reconstruct the actual code that exhibited the problem, you may have to pass this one off as an unsolvable mystery. If something like it happens again, please be sure to post the actual code, with variable declarations, and not your paraphrasing or outline of it.
