# How to treat a struct with two unsigned shorts as if it were an unsigned int? (in C)

I created a structure to represent a fixed-point positive number. I want the numbers in both sides of the decimal point to consist 2 bytes.

``````typedef struct Fixed_t {
unsigned short floor; //left side of the decimal point
unsigned short fraction; //right side of the decimal point
} Fixed;
``````

Now I want to add two fixed point numbers, `Fixed x` and `Fixed y`. To do so I treat them like integers and add.

``````(Fixed) ( (int)x + (int)y );
``````

But as my visual studio 2010 compiler says, I cannot convert between `Fixed` and `int`.

What's the right way to do this?

EDIT: I'm not committed to the `{short floor, short fraction}` implementation of Fixed.

Some magic:

``````typedef union Fixed {
uint16_t w;
uint32_t d;
} Fixed;
#define Floor w[((Fixed){1}).d==1]
#define Fraction w[((Fixed){1}).d!=1]
``````

Key points:

• I use fixed-size integer types so you're not depending on `short` being 16-bit and `int` being 32-bit.
• The macros for `Floor` and `Fraction` (capitalized to avoid clashing with `floor()` function) access the two parts in an endian-independent way, as `foo.Floor` and `foo.Fraction`.

Edit: At OP's request, an explanation of the macros:

Unions are a way of declaring an object consisting of several different overlapping types. Here we have `uint16_t w;` overlapping `uint32_t d;`, making it possible to access the value as 2 16-bit units or 1 32-bit unit.

`(Fixed){1}` is a compound literal, and could be written more verbosely as `(Fixed){{1,0}}`. Its first element (`uint16_t w;`) gets initialized with `{1,0}`. The expression `((Fixed){1}).d` then evaluates to the 32-bit integer whose first 16-bit half is 1 and whose second 16-bit half is 0. On a little-endian system, this value is 1, so `((Fixed){1}).d==1` evaluates to 1 (true) and `((Fixed){1}).d!=1` evaluates to 0 (false). On a big-endian system, it'll be the other way around.

Thus, on a little-endian system, `Floor` is `w` and `Fraction` is `w`. On a big-endian system, `Floor` is `w` and `Fraction` is `w`. Either way, you end up storing/accessing the correct half of the 32-bit value for the endian-ness of your platform.

In theory, a hypothetical system could use a completely different representation for 16-bit and 32-bit values (for instance interleaving the bits of the two halves), breaking these macros. In practice, that's not going to happen. :-)

You could attempt a nasty hack, but there's a problem here with endian-ness. Whatever you do to convert, how is the compiler supposed to know that you want `floor` to be the most significant part of the result, and `fraction` the less significant part? Any solution that relies on re-interpreting memory is going to work for one endian-ness but not another.

You should either:

(1) define the conversion explicitly. Assuming `short` is 16 bits:

``````unsigned int val = (x.floor << 16) + x.fraction;
``````

(2) change `Fixed` so that it has an `int` member instead of two shorts, and then decompose when required, rather than composing when required.

If you want addition to be fast, then (2) is the thing to do. If you have a 64 bit type, then you can also do multiplication without decomposing: `unsigned int result = (((uint64_t)x) * y) >> 16`.

The nasty hack, by the way, would be this:

``````unsigned int val;
assert(sizeof(Fixed) == sizeof(unsigned int))              // could be a static test
assert(2 * sizeof(unsigned short) == sizeof(unsigned int)) // could be a static test
memcpy(&val, &x, sizeof(unsigned int));
``````

That would work on a big-endian system, where Fixed has no padding (and the integer types have no padding bits). On a little-endian system you'd need the members of Fixed to be in the other order, which is why it's nasty. Sometimes casting through memcpy is the right thing to do (in which case it's a "trick" rather than a "nasty hack"). This just isn't one of those times.

If you have to you can use a union but beware of endian issues. You might find the arithmetic doesn't work and certainly is not portable.

``````typedef struct Fixed_t {
union {
struct { unsigned short floor; unsigned short fraction };
unsigned int whole;
};
} Fixed;
``````

which is more likely (I think) to work big-endian (which Windows/Intel isn't).

This is not possible portably, as the compiler does not guarantee a `Fixed` will use the same amount of space as an `int`. The right way is to define a function `Fixed add(Fixed a, Fixed b)`.

Just add the pieces separately. You need to know the value of the fraction that means "1" - here I'm calling that `FRAC_MAX`:

`````` // c = a + b
void fixed_add( Fixed* a, Fixed* b, Fixed* c){
unsigned short carry = 0;
if((int)(a->floor) + (int)(b->floor) > FRAC_MAX){
carry = 1;
c->fraction = a->floor + b->floor - FRAC_MAX;
}
c->floor = a->floor + b->floor + carry;
}
``````

Alternatively, if you're just setting the fixed point as being at the 2 byte boundary you can do something like:

``````void fixed_add( Fixed* a, Fixed *b, Fixed *c){
int ia = a->floor << 16 + a->fraction;
int ib = b->floor << 16 + b->fraction;
int ic = ia + ib;
c->floor = ic >> 16;
c->fraction = ic - c->floor;
}
``````

Try this:

``````typedef union {
struct Fixed_t {
unsigned short floor; //left side of the decimal point
unsigned short fraction; //right side of the decimal point
} Fixed;
int Fixed_int;
}
``````

If your compiler puts the two short on 4 bytes, then you can use memcpy to copy your int in your struct, but as said in another answer, this is not portable... and quite ugly.

Do you really care adding separately each field in a separate method? Do you want to keep the integer for performance reason?

``````// add two Fixed
Fixed operator+( Fixed a, Fixed b )
{
...
}

``````*(newtype *)&var