I'm a little confused about how the C language treats different sized ints when you do basic arithmetic and bitwise operation. what would happen if in this case:

```
int8_t even = 0xBB;
int16_t twice = even << 8;
twice = twice + even;
```

What If i went the other way and attempted to add a 16 bit int to an 8 bit? is the normal int declaration dynamic? Why would i want to designate a size? What happens when I add to 8 bit ints that are both 0xFF?

# Best How To :

As I mentioned in my comment, everything gets promoted to at least an int during arithmetic.

Here's an example program to demonstrate that:

```
main(){
struct {
char x : 1;
}t;
t.x = 1;
int i = t.x << (sizeof i * 8 - 1);
printf("i = %x\n",i);
}
```

`t.x`

is only one bit, but in this operation it is promoted all the way to an integer to give the output:

```
i = 80000000
```

On the other hand, if we add the line

```
long long j = t.x << (sizeof j * 8 - 1)
```

gcc gave me the warning:

```
warning: left shift count >= width of type [enabled by default]
```

**What If i went the other way and attempted to add a 16 bit int to an 8 bit?**

All the arithmetic would be done at integer precision (probably 32 bits) and then the bottom 8 bits of the result would be stored in the 8 bit number.

**Is the normal int declaration dynamic?**

No. Its a fixed width on an implementation (probably 32 bits on yours).

**Why would i want to designate a size?**

Maybe you have space constraints. Maybe your algorithm was made to work with a specific size integer. Maybe you really want to work on some modulo field provided by uint16_t (Z_65536).

**What happens when I add to 8 bit ints that are both 0xFF?**

The promotion doesn't matter here, the 8 bit result will be 0xFE. If you were to store the result in a 16 bit number, then the result will be 0x1FE (Unless int's in your implementation are only 8 bits. This is highly unlikely except for some esoteric embedded applications).

*Edit*

I wrote about the unsigned convention here, because you representing the number as 0xFF seemed to refer to unsigned numbers (in K&R C `0xFF`

is actually an unsigned literal). If you were actually referring to the signed 8-bit value 0xFF that is equivalent to -1, and your problem becomes sort of trivial. No matter how big the integer, it should always be able to represent -1, as well as `-1 + (-1) = -2`

(you only actually need two bits to represent these numbers).