integer overflow in a PIC -- where's the flow go?

Question

Working with a Microchip 18f4620 PIC. This should be a standard ANSI C question, though.

Say I have

unsigned int16 badFlow=65535 //max unsigned int16 value

This has a binary value of 1111 1111 1111 1111.

if I then

badFlow++;

the bit pattern becomes 1 0000 0000 0000 0000 17 bits. Obviously badFlow == 0, but the additional flipped bit either

gets discarded
or resides at wherever byte* flowPtr = &badFlow+2; points.

I'm assuming the latter, but hoping for the former.

My problem: a coworker has written some bad code with a counter that has been overflowing on all produced products for ~2 years. Considering what our customers charge for use of these tools, that's a few million dollars in peril due to potentially bad data.

@Mysticial yeah. And that has been corrected. I'm just trying to figure out if we need to go back and fix the past misbehaviour. — Sheriff, Jan 09 '12 at 18:30
I don't think #2 is valid - `resides at wherever byte* flowPtr = &badFlow+2;` — Sangeeth Saravanaraj, Jan 09 '12 at 18:31
This might be very late, but I'm curious; what is your compiler? — abdullah kahraman, Jul 06 '12 at 19:22

score 7 · Accepted Answer · answered Jan 09 '12 at 18:41

Arithmetic in C takes place with values, not bytes in memory. Your expression badFlow++ is equivalent to badFlow = badFlow + 1. The right-hand side is evaluated as type int (due to default promotions, assuming int is larger than 16 bits; if int is only 16 bits then it would be evaluated as unsigned int) resulting in 65536, then when 65536 is assigned into an unsigned 16-bit variable, it is reduced modulo 65536, resulting in 0.

The important thing to get out of this answer is that badFlow++ is not a direct operation on the memory at &badFlow (although it could possibly be implemented as such on some implementations). It's simply shorthand for an addition and assignment.

Thank you. That was really instructive – Sheriff Jan 09 '12 at 18:48 — Sheriff, Jan 09 '12 at 18:48

score 5 · Answer 2 · answered Jan 09 '12 at 18:30

5

The most significant digit gets discarded. Many processors will have a status register that indicates that an overflow occurred, but that is not visible from C (you'd have to work in assembly to use it)

answered Jan 09 '12 at 18:30

Joseph Stine

1,022
1
12
23

That is visible from C. XC8 compiler will allow you to read the status register, for example. I think all of the compilers will allow that. – abdullah kahraman Jul 06 '12 at 19:45
1

It's not part of standard C. Some compilers do provide a means of accessing it (usually an assembly macro), but it's system dependent. – Joseph Stine Jul 09 '12 at 18:15

score 4 · Answer 3 · answered Jan 09 '12 at 18:29

4

It will not overflow into memory that follows badFlow.

answered Jan 09 '12 at 18:29

NPE

486,780
108
951
1,012

score 4 · Answer 4 · answered Jan 09 '12 at 18:30

4

Option 1 is correct, the overflow is silently discarded.

answered Jan 09 '12 at 18:30

Joachim Isaksson

176,943
25
281
294

Jonathan Grynspan · Answer 5 · 2012-01-09T19:17:16.483

4

Overflowing or underflowing an integer type in standard C is generally a safe operation and will not modify memory beyond the bounds of the variable being accessed. In standard C, the overflow bit is discarded, though the implementation may store it in a special overflow register or dedicated memory location. For instance, on i386 systems, overflow is signalled in the "carry flag."

Edit: As @aix points out, the carry flag isn't updated by every relevant i386 assembly instruction. This is an implementation detail of course; the C language doesn't give two hoots about carry flags.

Edit 2: And as R. points out, signed overflow is undefined behaviour, though every implementation I've seen still treats it safely.

edited Jan 09 '12 at 19:17

answered Jan 09 '12 at 18:31

Jonathan Grynspan

43,286
8
74
104

Note that the i386 remark is only partially accurate: the INC (increment) instruction does **not** change the carry flag. – NPE Jan 09 '12 at 18:34
-1 this answer is plain wrong unless you qualify it with **unsigned**. Signed integer overflow is dangerous UB. – R.. GitHub STOP HELPING ICE Jan 09 '12 at 18:37
Fair enough. Updating answer. – Jonathan Grynspan Jan 09 '12 at 19:16
Your update is even worse because it shows you know about UB but don't care, and because it's **wrong**. Signed overflow does not behave as modular arithmetic on gcc or other modern compilers as of 5-10 years ago. – R.. GitHub STOP HELPING ICE Jan 09 '12 at 22:19
I didn't say anything about modular arithmetic. I just said that i know of no compiler that becomes dangerous (ie. crashes, writes to the wrong memory, etc.) when presented with signed overflow. And since the original question asked about unsigned overflow, the distinction isn't really important when answering. – Jonathan Grynspan Jan 10 '12 at 00:07

score 0 · Answer 6 · answered Jan 09 '12 at 18:32

0

Moving to uint32 and making a new software release would be the right way to go..

answered Jan 09 '12 at 18:32

Sangeeth Saravanaraj

16,027
21
69
98

yes. definitely the plan here. It's a big debacle to push the new release (involving travel and lots of mechanical work) but we'll be doing it. – Sheriff Jan 09 '12 at 18:35

integer overflow in a PIC -- where's the flow go?

6 Answers6