tags:

views:

9856

answers:

9

I'm working with embedded C for the first time. Although my C is rusty, I can read the code but I don't really have a grasp on why certain lines are the way the are. For example, I want to know if a variable is true or false and send it back to another application. Rather than setting the variable to 1 or 0, the original implementor chose 0xFF.

Is he trying to set it to an address space? or else why set a boolean variable to be 255?

+9  A: 

0xFF sets all the bits in a char. The original implementer probably decided that the standard 0 and 1 wasn't good enough and decided that if all bits off is false then all bits on is true. That works because in C any value other than 0 is true. Though this will set all bytes in a char, it will also work for any other variable type, since any one bit being set in a variable makes it true.

QuantumPete

QuantumPete
0xFF sets all the bits in a char. What it does to an integer is implementation/size/signed dependent
Steve Fallows
That's true, my mistake.
QuantumPete
As an aside, it's also the reason VB uses the value -1 for true values, and 0 for false values. -1 is all 1's in 2's compliment.
Kibbee
A: 
  • or else why set a boolean variable to be 255?

I'd say the real question is "why not?" ;-)

The boolean value of an integer/byte/whatever variable is often defined as 0->falsy, otherwise->truthy.

VolkerK
+1  A: 

0xFF is the hex representation of ~0 (i.e. 11111111)

In, for example, VB and Access, -1 is used as True.

Cade Roux
+1  A: 

As others have said, it's setting all the bits to 1. And since this is embedded C, you might be storing this into a register where each bit is important for something, so you want to set them all to 1. I know I did similar when writing in assembler.

Paul Tomblin
+2  A: 

If you are in desperate need of memory, you might want to store 8 booleans in one byte (or 32 in a long, or whatever)

This can easily be done by using a flag mask:

  // FLAGMASK = ..1<<n for n in 0..7...
  FLAGMASK = 0x10;    // e.g. n=4

  flags &= ~FLAGMASK; // clear bit
  flags |= FLAGMASK;  // set bit
  flags ^= FLAGMASK;  // flip bit
  flags = (flags & ~FLAGMASK) | (booleanFunction() & FLAGMASK); // clear, then maybe set

this only works when booleanFunction() returns 0 (all bits clear) or -1 (all bits set).

mfx
+2  A: 

Often in embedded systems there is one programmer who writes all the code and his/her idiosyncrasies are throughout the source. Many embedded programmers were HW engineers and had to get a system running as best they could. There was no requirement nor concept of "portability". Another consideration in embedded systems is the compiler is specific for the CPU HW. Refer to the ISA for this CPU and check all uses of the "boolean".

humble_guru
A: 

What's really important to know about this question is the type of "var". You say "boolean", but is that a C++/C99's bool, or is it (highly likely, being an embedded C app), something of a completely different type that's being used as a boolean?

XPav
A: 

Here's a likely reason: 0xff is the binary complement of 0. It may be that on your embedded architecture, storing 0xff into a variable is more efficient than storing, say, 1 which might require extra instructions or a constant stored in memory.

Or perhaps the most efficient way to check the "truth value" of a register in your architecture is with a "check bit set" instruction. With 0xff as the TRUE value, it doesn't matter which bit gets checked... they're all set.

The above is just speculation, of course, without knowing what kind of embedded processor you're using. 8-bit, 16-bit, 32-bit? PIC, AVR, ARM, x86???

(As others have pointed out, any integer value other than zero is considered TRUE for the purposes of boolean expressions in C.)

Dan
it's an 8051 chip
Dan
Well, there's nothing in the 8051 instruction set that would make it easier to set a register to 0xFF as opposed to 1. I'm stumped, maybe it's just the idiosyncratic habit of this particular coder, maybe it's an undocumented hack for some bit-manipulation trick used elsewhere, ...?
Dan
I'm inclined to believe it's the coder and not the hardware. I found out that this was his first embedded system, and he was let go for poor work.
Dan
A: 

Also adding 1 to 0xff sets it to 0( assuming unsigned char) and the checking might have been in a loop with an increment to break.

Vaibhav Garg