This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

variable name confusion

void tst()
{
  { char  x; _x = 0; } // ... error C202: '_x': undefined identifier
  { char _x;  x = 0; } // No errors! Are "_x" and "x" the same here?
}

  • The first error is expected; _x isn't visible by the time it's referenced.

    For the second error, it seems more likely that C51 doesn't correctly remove 'x' when it goes out of scope. It might also be an odd consequence of the C89 definition. I'd have to do some standards-lawyering to see exactly what changed with local blocks between C89, C++, and C99. Note that Keil doesn't claim to be C99 compliant anyway.

    Identifiers that begin with an underscore are reserved for the language or implementation and shouldn't be used. (Yes, I know some people like to do this in libraries, and they even get away with it. The standard libraries are one reason that range of identifiers is reserved. That doesn't mean everyone else should do it, too.)

  • void tst()
    {
      { char  x; _x = 0; } // ... error C202: '_x': undefined identifier
      { char _x;  x = 0; } // No errors! Are "_x" and "x" the same here?
    }
    

    Drew Davis wrote:
    For the second error, it seems more likely that C51 doesn't correctly remove 'x' when it goes out of scope.

    This is wrong - the following code will be compiled without error message:

    void tst()
    {
      { char _x;  x = 0; } // No errors! Are "_x" and "x" the same here?
    }
    

    and "_x" and "x" are really the same here.

    Drew Davis wrote:
    Identifiers that begin with an underscore are reserved for the language or implementation and shouldn't be used...
    This is correct and may be a reason of the Keil C51 compiler bug (IMHO). The variable names "x" and "_x" should be different... :-(

  • Drew Davis wrote:
    Identifiers that begin with an underscore are reserved for the language or implementation and shouldn't be used...
    This is correct

    Actually, it's not. Identifiers with a leading underscore are reserved only if either

    a) the second character is also an underscore,
    b) the second character is upper-case, or
    c) the name is at file-scope.

    Neither of the above applies to the case at hand, a block-scoped variable with a lower-case second character.