1

I've been experimenting with changing values for some of the bits for field packing a byte, based on my last question: Field packing to form a single byte

However, I'm getting unexpected results based on the values. The top code sample gives me an expected output of 0x91, however if I change colorResolution and sizeOfGlobalColorTable variables to: 010, I get an unexpected output of 0x80 which isn't the binary representation of what it should be: 10100010 based from here: http://www.best-microcontroller-projects.com/hex-code-table.html. I would expect an output of: 0xA2 for the bottom code sample. What am I missing or not understanding?

This code correctly logs: 0x91

uint8_t screenDescriptorPackedFieldByte = 0;

uint8_t globalColorTableFlag = 1;
uint8_t colorResolution = 001;
uint8_t screenDescriptorSortFlag = 0;
uint8_t sizeOfGlobalColorTable = 001;

screenDescriptorPackedFieldByte |= ((globalColorTableFlag & 0x1) << 7);
screenDescriptorPackedFieldByte |= ((colorResolution & 0x7) << 4);
screenDescriptorPackedFieldByte |= ((screenDescriptorSortFlag & 0x1) << 3);
screenDescriptorPackedFieldByte |= ((sizeOfGlobalColorTable & 0x7) << 0);

NSLog(@"0x%02X",screenDescriptorPackedFieldByte);

This code incorrectly logs: 0x80

uint8_t screenDescriptorPackedFieldByte = 0;

uint8_t globalColorTableFlag = 1;
uint8_t colorResolution = 010;
uint8_t screenDescriptorSortFlag = 0;
uint8_t sizeOfGlobalColorTable = 010;

screenDescriptorPackedFieldByte |= ((globalColorTableFlag & 0x1) << 7);
screenDescriptorPackedFieldByte |= ((colorResolution & 0x7) << 4);
screenDescriptorPackedFieldByte |= ((screenDescriptorSortFlag & 0x1) << 3);
screenDescriptorPackedFieldByte |= ((sizeOfGlobalColorTable & 0x7) << 0);

NSLog(@"0x%02X",screenDescriptorPackedFieldByte);
Community
  • 1
  • 1
klcjr89
  • 5,862
  • 10
  • 58
  • 91

2 Answers2

4

This value is not binary. It is octal. 

uint8_t sizeOfGlobalColorTable = 010;

In (Objective) C constants starting from 0 are interpreted as octal values. What you actually write is b1000 & b0111 = 0.

It should be:

uint8_t sizeOfGlobalColorTable = 0x2;
Alex
  • 9,891
  • 11
  • 53
  • 87
  • I do not want hex values as the input, I want to use either 0's or 1's for my flags. – klcjr89 Apr 24 '15 at 17:49
  • @aviatorken89 As far as I saw in Google, there are no binary literals in Objective-C, so you will have to deal with it. At lease using Hex will give you working code. – Alex Apr 24 '15 at 17:55
  • Or I can just remove the leading zeros and all will be well? That is fine with me if that will make valid bytes. – klcjr89 Apr 24 '15 at 17:57
  • 1
    @aviatorken89 If you remove leading zeroes value will be *decimal*. In addition if you work with bits, it is much easier to deal with Hex values just because each 4 bits are one Hex symbol (e.g. `b1111` is `0xf`). – Alex Apr 24 '15 at 18:00
  • I'm still lost. If I plug in hex values instead of the decimals in the above question sample, the bit shifting messes up the output value now. – klcjr89 Apr 24 '15 at 18:06
  • @aviatorken89 I am not sure that I got you now. – Alex Apr 24 '15 at 18:09
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/76201/discussion-between-aviatorken89-and-alex). – klcjr89 Apr 24 '15 at 18:10
0

010 in C is octal (base 8) for the decimal 8.

The leading 0 makes the compiler assume you want an octal value, similar to the usage of the 0x prefix to indicate hexadecimal.

That will (correctly) result in 0 and 0 for lines 2&4 of the bit calculation. You want to just eliminate the leading 0 of 010 for decimal 10, or if you intended binary 010, 0x10.

hansmuff
  • 42
  • 3
  • So for flags with leading zeros, I can remove the leading zeros safely? – klcjr89 Apr 24 '15 at 17:52
  • In the case of your code, 001 is the same as decimal 1 so yes you can remove the leading zeros. – hansmuff Apr 24 '15 at 17:57
  • I think I just understood your question. If you intend to use hexadecimal for your numbers/flags, use leading 0x and you will not need leading zeros in the hexadecimal value. – hansmuff Apr 24 '15 at 18:05