programming follies.

Discussion in 'Mac Programming' started by farmerdoug, Feb 8, 2010.

  1. farmerdoug macrumors 6502a

    Sep 16, 2008
    I put two lines of code into my program

    if (strcmp(A,B))
    printf (.....)
    instead of
    if (strcmp(A,B) == 0)
    printf (.....)

    The program compiled which doesn't surprise me but why would it completely screw up the operation of the code?
  2. jared_kipe macrumors 68030


    Dec 8, 2003
    because the first one checks if they are different, and the second one checks if they are the same


    "Return Value

    Returns an integral value indicating the relationship between the strings:
    A zero value indicates that both strings are equal.
    A value greater than zero indicates that the first character that does not match has a greater value in str1 than in str2; And a value less than zero indicates the opposite."

    so in the first one, anything BUT the same strings will execute the printf
    in the second one, ONLY equal strings will execute the printf
  3. farmerdoug thread starter macrumors 6502a

    Sep 16, 2008
    try again

    When I said screw up, I really meant screw up. Values get increased for no apparent reason. Errors way beyond the print statement.
  4. chown33 macrumors 604

    Aug 9, 2009
    Post the actual code. You've obviously paraphrased the real code, because what you've posted can't possibly compile. At best, you've posted an outline of a hypothetical, and a vague summary of some problem.

    If we can't see what you're really compiling, why do you think we'd be able to analyze it, or comment on how it runs?
  5. jared_kipe macrumors 68030


    Dec 8, 2003
    You try again. Its a simple c function, won't "screw up data", and testing the return value from it against 0 obviously won't screw anything up.

    So either you didn't copy/paste right, or the if() statement is NOT the problem.

    Either way, set a breakpoint and debug it.

    Oh god, its this guy
    Even I am beginning to see a pattern...

    Ok, new guess, A and B aren't C strings?
    Maybe its the printf(....), though I think that will throw a compile time error ;)
  6. mac2x macrumors 65816

    Sep 19, 2009
    @ the OP: The good folks here are extremely helpful ( :) ), but you really need to get a book if you want to learn more effectively.
  7. farmerdoug thread starter macrumors 6502a

    Sep 16, 2008

    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.

    The code no longer exists; it was used for debugging; it look just about like this:
    char *a ;
    int *i, j

    a = (char *) calloc(12, sizeof (char);
    printf(" %d, %d\n", *i, j)
  8. Sander macrumors 6502

    Apr 24, 2008
    Oh I know. On line 34 of your file, you reference a function which you misspelled but which happens to be the same as a different function.

    It's obvious.

  9. chown33 macrumors 604

    Aug 9, 2009
    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.

    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.
  10. ChOas macrumors regular

    Nov 24, 2006
    The Netherlands

    Couldn't have said it better ;)

Share This Page