HC08 Condition always is TRUE

[BasePointer]

Hi,

Code:

#define  IND_CLOCK_DOTS LCD_RAM[12].Bit.R0=LCD_RAM[12].Bit.R1=LCD_RAM[15].Bit.R0=LCD_RAM[15].Bit.R1IND_CLOCK_DOTS = 1; ***

The second line of the code generates warning "Condition always is TRUE".
What does it mean?

CW 5.1 + HCS08 C

Thank you.

Message Edited by CrasyCat on 2007-04-13 10:58 AM

[Alban]

Hello,

I don't think you can do a series of equals to assign the latest to all previous.

Have you tried separating each statemement ?

I imagine the compiler took this as a logical test and as it is always different from zero, it is true.

Cheers,

Alban.

[BasePointer]

But it must be a ansi-c standart:

http://www.cs.cf.ac.uk/Dave/C/node4.html

Defining Global Variables Section:

Code:

C also allows multiple assignment statements using =, for example:           a=b=c=d=3;...which is the same as, but more efficient than:           a=3;  b=3;  c=3;  d=3;

 

[CompilerGuru]

Such chained assignments are legal in ANSI-C, but they are not equivalent to separate assignments.
For a.a=(b.b=3), the a.a= assignment assigns the result of the b.b=3 assignment, and this does not need to be 3.
Well, if b.b happens to be a one bit bitfield, then 3 does not fit into it and a.a gets assigned the cutted (and possibly sign extended) value which was stored in b.b.
Note that if b.b is volatile, we also will get additional code for reading it.

My guess is that your diagnostic message is caused by some condition which was inserted by the compiler to extract the bitfield value. Then the compiler did detects that this condition is known and he issues the diagnostic.

Well, you can raise an service request for not getting this diagnostic in your case, but independently of this, I would not use the chained assignments with bitfields. Well, I personally would not use them at all, it's a not so often seen C construct and therefore may confuse the readers of your code, it does not make the code more efficient, just a few characters shorter.

Daniel

PS: Please try to post complete compilable samples and not just such short snippets where important parts like the used types are missing.

[Lundin]

Also, bitfields themselves is a real pain. I can almost guarantee that they will make your code non-portable. I have yet to see two compilers implementing them in the same way. Things that usually mess up:

- Bitfields must be the same size as int according to the standard (ISO/IEC 9899:1999 6.7.2.1.4). If you use char or any other convenient integer type, you aren't following the standard. Sad but true.

- What happens when not all bits are specified? The standard states (6.7.2.1.10) that the bitfield should be packed together with another bitfield if there is space. If there isn't space, it is implementation-defined.

- At any rate we get big/little endian issues and they are of course not mentioned in the standard, since it knows nothing of endians. Which bit in the bitfield is MSB? Nobody knows.

- Struct padding.

- sizeof operator on bitfields.

And so on. This might be the dumbest part they included in the C standard. What you should do is to use bit masks and the bitwise operators instead, since the result will be same on all compilers. If the compiler is any good, it won't matter if you are using bitwise operators or using bitfields, it should yield -exactly- the same machine code in the end. Which is true for Codewarrior.