Interger Representation - Huh?!

[Jeff McCune]

Not sure if I missed something in my CIS classes, but can someone offer some insight into this behavior?

int foo;
foo = 127 + 127;
printf ("%16b | %d \r\n", foo, foo);
// prints: "1111 1111 1111 1110 | -2"


Is this a bug in the printf code, or is the compiler and microchip actually representing this using ones for the first 15 significant digits and a zero at the least significant position?

It would seem that it might be treating the literal values as an 8 bit integer and then padding with the most significant digit to get to 16 bits. "it" may be printf, or the compiler/CPU... ?

This code is my work around:

unsigned char foo;
foo = 127 + 127;
printf ("%16b | %d \r\n", (int)foo, (int)foo);
// prints: "0000 0000 1111 1110 | 254"

// This also works, keeping all my data types at (int)
// This also implies it's a bug in how the chip/compiler represents literal values
int foo;
foo = (int)(unsigned char)(127 + 127);
printf("%16b | %d \r\n", foo, foo);


From the last example, it would seem that literal values are padded out using the most significant digit, but this padding doesn't occur if you cast the data along the way. Am I correct in this guess?

Any insights? I'd like to just use one data type (int) everywhere, but this is hanging me up, since it becomes difficult to debug the output.

[gnormhurst]

Not sure if I missed something in my CIS classes, but can someone offer some insight into this behavior?

int foo;
foo = 127 + 127;
printf ("%16b | %d \r\n", foo, foo);
// prints: "1111 1111 1111 1110 | -2"


Is this a bug in the printf code, or is the compiler and microchip actually representing this using ones for the first 15 significant digits and a zero at the least significant position?

The compiler has a documented non-standard behavior that may relate to this. See below, from the C18 compiler reference manual (available on the Microchip site).

2.7 ISO DIVERGENCES

2.7.1 Integer Promotions
ISO mandates that all arithmetic be performed at int precision or greater. By default, MPLAB C18 will perform arithmetic at the size of the largest operand, even if both operands are smaller than an int. The ISO mandated behavior can be instated via the -Oi command-line option.

For example:

unsigned char a, b;
unsigned i;
a = b = 0x80;
i = a + b; /* ISO requires that i == 0x100, but in C18 i == 0 */

Note that this divergence also applies to constant literals. The chosen type for constant literals is the first one from the appropriate group that can represent the value of the constant without overflow.

For example:

#define A 0x10 /* A will be considered a char unless -Oi specified */
#define B 0x10 /* B will be considered a char unless -Oi specified */
#define C (A) * (B)
unsigned i;
i = C; /* ISO requires that i == 0x100, but in C18 i == 0 */


=====

It is confusing. I think you could cast the literal as an (int):

foo = (int)127 + (int)127;
Or maybe this?

foo = 127L + 127L;
I haven't tried these.

[deltacoder1020]

just make sure you cast all of the variables you pass to printf as (int).

[Jeff McCune]

gnormhurst,
Thank you for that incredibly detailed, quick, and accurate post. I'll make sure to read the C18 tech docs as soon as I can find the time. So far I've been very happy with how compliant the compiler is. I think you hit the nail on the head.

I hacked a macro to manipulate the datatypes I wanted to work with, but I *hate* macros. I think I might just use the command line option you mentioned, after I research it's overall implications.

deltacoder1020,
If you look over my examples, the type of data I was passing to printf was already int. re-casting it inside the printf statement won't change anything.

[deltacoder1020]

sry about that, perhaps I was unclear - essentially, MCC18 casts any constant from 0-255 as a unsigned char, so you may want to cast the constants as well.