Why does uint16_t make a difference here?

Question

volatile uint16_t r;
unsigned char poly = 0x07;
unsigned char c = 0;

r = (c << 8) ^ poly;

When the code is compiled with gcc on Linux, r is 7.
When the same code is compiled by Microchip C18, r is 0.
Why?

If I change it to:

volatile uint16_t r;
uint16_t poly = 0x07;
uint16_t c = 0;

r = (c << 8) ^ poly;

r becomes 7 in C18, too.

There is a section about integer promotion in the C18 manual, but I don't think it has something to do with my question. Anyway, here it is:

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.

What happens on C18 for `r = c ^ poly;` or `r = (0) ^ poly;`? Have you tried the `-Oi` switch as suggested by the manual? — Adam, May 23 '11 at 01:06
In both cases it's still 0 but with the -Oi option enabled it is 7. — AndreKR, May 23 '11 at 02:12
Then use `-Oi` and complain to your compiler vendor that their compiler is broken-by-default... — R.. GitHub STOP HELPING ICE, May 23 '11 at 02:17

score 3 · Accepted Answer · answered May 23 '11 at 02:09

3

Since c << 8 is undefined in this compiler, the result of xor can't be predicted. The result could be anything the compiler chooses.

See What Every C Programmer Should Know About Undefined Behavior for an introduction to undefined behavior, especially the section "Oversized Shift Amounts".

answered May 23 '11 at 02:09

ergosys

47,835
5
49
70

`c<<8` is not undefined on any C implementation. – R.. GitHub STOP HELPING ICE May 23 '11 at 02:16
2

@R, standard C will promote to int. This compiler apparently does not as noted by the OP. So the operation is essentially an oversized shift, AFAICT. – ergosys May 23 '11 at 02:34
I opened a ticket with Microchip to confirm. – AndreKR May 23 '11 at 16:23
Microchip confirmed that casting c to int is necessary, so the answer seems correct. – AndreKR Jul 04 '11 at 23:21

score 2 · Answer 2 · answered May 23 '11 at 00:50

2

c << 8 with c a char is basically sending all the bits to oblivion. As specified in the doc, both c and 8 fit in a char, so everything is done using char.

c << 8UL may change the deal.

answered May 23 '11 at 00:50

Joel Falcou

6,247
1
17
34

This explains what happens to `c` if any of the bits were set, but doesn't explain why the `^ poly` fragment disappears too. – viraptor May 23 '11 at 00:54
1

Actually, the standard also says that shifting an integer of size `n` bits by `n` is undefined behavior, so who knows what shifting a char by 8 does on this compiler? (note: on a standard compiler, `c<<8` is defined by virtue of the promotion to `int` that this compiler removes) – Pascal Cuoq May 23 '11 at 01:21
Oh, interesting. That explains why the results I am getting are, well, undefined. I even managed to get 0x62 instead of 0x00 and in another variant I got a disassembly that completely ignored that line. That's the answer I guess. – AndreKR May 23 '11 at 02:14

Why does uint16_t make a difference here?

2 Answers2