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

BUG with bits in integer variable

There is a BUG in the compilation of a bit definition:

unsigned int bdata my_int;
sbit bit15 = my_int ^ 15;
sbit bit7 = my_int ^ 7;

void main()
{
  my_int = 0x8000;

  if(bit15)
  {
    // Here we shall not appear,as compiller
    // will be erroneous to check 7-bit of
    // a variable my_int instead of 15-bit
    // (as this variable place in memory in
    // little endian order)
    // ...
  }

  if(bit7)
  {
    // oops! we here!
    // ...
  }
}
This is a BUG! Please correct. Thanx.

Parents
  • That only people will not think up to explain the absurds!
    it is crystal clear from your post that you have refused to even glance at the '51 architecture. Had you done so, the explanation would have been crystal clear.

    Well, since you refuse to study the '51 architecture, one comment

    Good luck, you will need it

    Erik

    for your sake I hope I'm wrong.

Reply
  • That only people will not think up to explain the absurds!
    it is crystal clear from your post that you have refused to even glance at the '51 architecture. Had you done so, the explanation would have been crystal clear.

    Well, since you refuse to study the '51 architecture, one comment

    Good luck, you will need it

    Erik

    for your sake I hope I'm wrong.

Children
  • Do not stir bosh. Speak to the point. I have studied '51 architecture at once as soon as it has appeared. As it is the one-byte controller all other "wide" types of data are added by C-compiler. So C-compiler knows as data place in memory and it can take the necessary byte and to analyse necessary bit. I have declared the integer (16-bits) and I want at it 14-th bit. Instead of it I for some reason should read any ridiculous explanations and specify 6-bats. Unless it not absurdity?