It's the same reasoning as in C: the size of the
int type is expected to be the natural word size that your system handles most efficiently. It must also be at least 16 bits wide, no smaller than a
short, and no larger than a
int may be 16-, 32-, or 64-bits, based on the whatever your system handles best, and so is most likely to be 16 bits wide on an 8- or 16-bit CPU, 32 on a 32-bit CPU etc.
int when I want the best performance, whilst taking care to guard when I need more range than offered by 16 bits. These days, you tend to know when you are writing application code for 16-bit systems, although that's not so true for "library" code where portability may be of greater concern.
In your example, assuming the author had chosen their types carefully, the
int variables probably require a small range and could afford to be word-size, leading to potentially shorter or faster code (or both). The
long ones presumably required more than 16-bit range (they are guaranteed to be at least 32 bits wide). On the processor you'd selected as a compilation target, it looks like
long were both implemented as 32-bit; this would be different (or should be) if you selected a 16-bit target CPU.