Should I trust that a short in C will be 2 bytes usually?

Question

I have a large number that loops from 0 to 65535 (I chose 16 bits simply to have a nice cutting off point). I'm incrementing an int, and there's an if statement that checks if the int is 65536. If it is, it sets the int to 0; a little kludgy, but it works. I know it would be much more efficient to just use a short int and let it overflow, but I initially didn't do that because a short is not guaranteed to be 2 bytes, it's just fairly likely.

This is C code running on a linux (ubuntu) machine. If I were to use a short and later decided to run this program on another OS (or say, run it on a 64-bit machine, since I'm testing on a 32-bit one now), is there a pretty good chance that my short will still be 2 bytes? I can easily test it on a few different machines, but some of the people here have worked with a LOT of computers. Is there a terrible pitfall I should be watching out for?

Answer 1

There is no guarantee of the size of any of the built-in types like int, char and the like. (See for example this question, which is about C++, but is also accurate for C as far as I know in this regard)

If you need fixed-size integer types, include C99's <stdint.h> and use the fixed-width typesdefined there.

Answer 2

Short is 16 bits on the vast majority of compilers. If at all reasonable, I'd probably use a bit-field for the job:

struct { 
    unsigned short my_number : 16;
};

In a typical case where short is 16 bits anyway, this won't impose any overhead -- and in the rare case that some extra code needs to be inserted to clamp the value to the right range, this handles that automatically.

The only shortcoming is that you can only have a bit-field inside a struct.

Edit: It's unfortunate that @earlz deleted his answer, because his idea was actually better than he thought: if a C99 implementation has a 16-bit unsigned integer type, it's required to provide uint16_t as a typedef for that type. If provided, this must be exactly 16 bits wide. There's also a uint_least16_t that fits his description (at least 16 bits wide, but could be more).

Answer 3

No, the only thing you can assume is that shorts are not larger than ints.

If you want to wrap around to 0 after 65535 without a test, you can do it this way:

unsigned int i;
...

i = (i + 1) & 0xffff;

Answer 4

There's no guarantee that short is 16 bits - e.g. I've used a compiler that used 32 bits for a short because it was much more efficient to do this than use 16 bits. (On ARM architecture)

However, it's dead easy to use a type that is guaranteed to be 16 bits, and you can add an assertion check that will warn you as soon as you try to use a compiler where this isn't true:

ASSERT(sizeof(short) == 2);

Answer 5

A short is going to be however long sizeof says it is. The C standard says that a short is required to be at least sixteen bits. It is not required to be smaller than an int, though it often is.

Answer 6

Find the platform MAX_SHORT by using sizeof(short), and iterate until you hit that.

Answer 7

If you obey C99, then you can assume safely that:

a `short int` may have a minimum value of `-32767`
                         maximum value of `+32767`
an `unsigned short int` may have a minimum value of `0`
                                   maximum value of `65535`

And so on, as witnessed in 5.2.4.2.1 Sizes of integer types <limits.h> of the standard. Noting of course that the standard explicitly notes that the maximum values defined in said section, are to be the size of, or smaller than the implementation defined sizes. Therefore, the size of a short or unsigned short, may be larger than what I just posted above. However, it will not be larger than an int.

Answer 8

Use uint16_t, or if you insist you can use a larger type and perform x %= 65536; or x &= 65535 on each iteration. I guarantee this is a lot faster than performing a conditional to reset it to zero.