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

Warning C258 in Keil C51 V7.02b

After upgrading to 7.02b, I get a C258 Warning when using the typedef in the following example.

If I use 'bit' directly, the Warning is not issued.

Any clues?

Best regards and thanks in advance.

Jose


volatile unsigned char c1, c2, c3;

typedef bit BOOL;

unsigned char func1(BOOL a, unsigned char b)
{
  if (a) return b;
  else return ~b;
}

void main(void)
{
  c1 = func1(0, 9);
  c2 = func1(1, 8);
}

  • Some more information on the issue:

    If the parameters are swapped, the Warning is not issued. In the following example,
    func1 generates the following warning:

    MAIN.C(5): warning C258: 'b': mspace on parameter ignored
    

    but func2 compiles ok.

    Jose

    unsigned char func1(BOOL a, unsigned char b)
    {
      if (a) return b;
      else return ~b;
    }
    
    unsigned char func2(unsigned char b, BOOL a)
    {
      if (a) return b;
      else return ~b;
    }
    

  • typedef bit BOOL;
    Yes, that'd be really useful, wouldn't it!
    But, unfortunately, Keil doesn't quite seem to work that way. :-(

    It seems that the bit keyword is not so much a new type - in addition to char, int, etc - introduced by C51, but another of the memory-space qualifiers like idata, xdata, etc
    Hence the warning relating to m-space

    I don't think the distinction is made particularly clear in the manual. :-(

  • I can understand that, but I am mystfied by the behaviour of the compiler.

    If the 1st parameter is a BOOL, then a warning is issued.

    If the 2nd parameter is a BOOL, no warning is issued.

    Any clues?

    Jose

  • "Any clues?"

    Take a look at the section in the manual which describes C51's parameter passing;
    There are certain issues about the order of parameters of different types - especially bits.

  • The problem is not just related to bit, I had a similar problem with a typedef specified that variables of the given type should be placed in xdata.

    As noted by an earlier corespondent, bit is not a C type but an 8051 memory space.

    It seems that the compiler has been updated to detect and warn about types that specify a memory space being used in parameter lists. It may be a side-effect of other compiler updates designed to improve error checking.

    Acutally, I find this new feature inconvenient. Perhaps this warning could optionally be suppressed in the same way that it is possible to suppress some linker warnings.

    [rant]

    This affair brings me back to an old gripe of mine. C51 does not allow variables stored in bit memory to have a type - it should. It would be convenient and consistent to be able to place a variable of an enumerated type that has only 0 and 1 as possible values, in bit memory.

    The most obvious such types are, of course, booleans. But there are also all sorts of other binary states such as on/off, high/low stop/go, passed/failed etc.

    If C51 allowed bit variables to have a C type in this way then clearer software would result and, if you so choose, strong typeing rules can be properly enforced.

    Also, since the same enumerated types can fit into larger spaces (8-bits for example) the same types can be used in parameter lists.

    [/rant]