It is only indirectly a problem.
Bad things can happen if you use signed integers for bitwise operations such as &
, |
, <<
and >>
.
Completely different bad things can happen if you use unsigned integers for arithmetic (underflow, infinite loops when testing if a number is >= 0
etc.)
Because of this, some compilers and static checking tools will issue warnings when you mix signed and unsigned integers in either type of operation (arithmetic or bit manipulation.)
Although it can be safe to mix them in simple cases like your example, if you do that it means you cannot use those static checking tools (or must disable those warnings) which may mean other bugs go undetected.
Sometimes you have no choice, e.g. when doing arithmetic on values of type size_t
in memory management code. (I can't remember if size_t
is required to be unsigned by C89 or C99, but it has always been unsigned in every implementation I have seen.)
In your example I would stick to int
, just because it is simpler to have fewer types, and the int
is going to be in there anyway as it is the type of the first argument to main()
.