Signed integer addition, clarification needed

Question

I have the following signed integers:

(4bits)a = 6;
(4bits)b = 7;
(4bits)c;
c = a + b;

Will c = 13 or c= -3? If I do binary math and assume it's a 4 bit number: 0110+0111=1101 (-8 + 4 + 0 + 1) = -3

According to the 2nd edition of the C programming Language, a 4-bit machine shall have a 4 bit int in general. I believe it's not even mandated that an int is a 1 or 2-complement system (1-complement means that 1 bit is used as signed flag, so you loose one negative number but get a -zero in return). — Roalt, Jun 18 '11 at 21:13
@Roalt: If the 2nd edition of "The C Programming Language" really says that, then it's wrong. K&R 2ed is supposed to include ANSI standard C, aka C89, but C89 says that the minimum permissible value of `INT_MAX` is `32767` (2.2.4.2 Numerical limits). So `int` must not be a 4 bit type. — Steve Jessop, Jun 18 '11 at 21:17
Bitfields are irrelevant. The values will always be promoted at least to `int` for arithmetic. After that, assignment back into a smaller bitfield type will produce implementation-defined value or signal if the actual value does not fit. — R.. GitHub STOP HELPING ICE, Jun 18 '11 at 21:56
Why is this a question? This only matters for bit-slices and 4-bit processors, they went the way of the dodo at least 30 years ago. The only person interested in your answer is your teacher. — Hans Passant, Jun 18 '11 at 22:07

Steve Jessop · Accepted Answer · 2011-06-18T21:15:02.260

Contrary to popular belief, C does have 4-bit integer types. However, it doesn't have objects of those types, only bit-fields (6.7.2.1/9, "A bit-ﬁeld is interpreted as a signed or unsigned integer type consisting of the specified number of bits"):

#include <stdio.h>

typedef struct int4bit {
    signed int value:4;
} int4bit;

int main() {
    int4bit a, b, c;
    a.value = 6;
    b.value = 7;
    c.value = a.value + b.value;
    printf("%d\n", c.value);
}

The output of this program with my compiler is -3, however this is not guaranteed by the standard. The reason is that the expression a.value + b.value has type int (because of integer promotion rules, 6.3.1.1/2), and value 13. The value 13 cannot be represented in a 4 bit signed integer, and therefore one of two things happens: either an implementation-defined result or an implementation-defined signal (6.3.1.3/3).

In short, all you can do is check your compiler documentation, or run the code and see what it does. But this result, -3, is pretty natural for an implementation with 2s complement representation of signed integer types.

The value can't be 13, because 13 is not in the range of values representable by a 4 bit signed integer. Anything is permitted as long as the implementation documents it, for example it could naturally be -2, on a 1s' complement machine with no overflow checking. Not that you'll likely ever encounter such a machine...

That's something of a special case because the only way to get a 4 bit integer type is as a bit-field. In general, overflow of signed integer arithmetic is undefined behavior (6.5/5, "result is ... not in the range of representable values for its type"). There's no arithmetic overflow in your example because of the promotion to int, so the range of behavior available to the implementation is limited - it's not allowed to format your hard drive. But if you do overflow an int then you're totally at the mercy of your compiler.

score 5 · Answer 2 · answered Jun 18 '11 at 20:07

5

If ints in the system you are using are 4 bits long then indeed the result will overflow and the result will be -3. However in C ints are atleast 16-bit and therefor the result will be 13.

answered Jun 18 '11 at 20:07

Sani Huttunen

23,620
6
72
79

Nothing in the C standard mandate a two's complement representation. – BatchyX Jun 18 '11 at 20:14
@BatchyX: No there isn't but as I wrote: "in the system you are using". If the OP interprets 1101 as a two's complement representation then the result is -3 in a 4-bit system. Since ints are atleast 16-bit the question is moot. I think the OP want's to understand two's complement representation and overflow arithmetics. – Sani Huttunen Jun 18 '11 at 20:21

score 1 · Answer 3 · answered Jun 18 '11 at 20:11

The result of the operation is behavior-specific. C doesn't mandate that the architecture must use two's complement representation (even if nearly all do).

But you should rewrite your example with bigger numbers, as people here are confused with your "let's pretend int is 4bit" thing.

score 0 · Answer 4 · answered Jun 18 '11 at 20:06

0

It's 13. ints in C are guaranteed to be at least 16 bits.

answered Jun 18 '11 at 20:06

Graham Borland

60,055
21
138
179

According to The C Programming Language 2nd edition, page 157: "Plain int objects have the natural size suggested by the host machine architecture". It may vary with another book edition though. – Roalt Jun 18 '11 at 21:11
@Roalt: K&R doesn't define the language any more, ISO/IEC 9899:TC3 (aka C99) does. Or C89 if you're Microsoft. There hasn't been an edition of K&R since 2nd, it's a nice enough introduction to the language but it's out of date. That text about "natural size" is in both standards, but you have to read it in conjunction with the lower limits. If you want to be really critical, arguably it's a defect in the standard that it (a) doesn't define "natural size", and/or (b) appears to make contradictory requirements. Implementers don't pay much attention to "natural size". – Steve Jessop Jun 18 '11 at 21:22

score 0 · Answer 5 · edited May 23 '17 at 12:04

Did you try this in a compiler? There's one availble for free on the web...

http://codepad.org/MHUee7hx

#include "stdio.h"

int main(int argc, char* argv)
{
  int a = 6;
  int b = 7;
  int c;
  c = a + b;
  printf("%i\n", c);
  return 0;
}

13

In addition, there is no 4-bit int in C. If you have a 4-bit int, you're not using a standard-compliant version of C.

See this question - What is the difference between an int and a long in C++?

Particularly Martin's answer.

Signed integer addition, clarification needed

5 Answers5