For all integer types except char, 'signed' is implicit, so plain 'long'
is the same as 'signed long'.

char may be signed or unsigned - it is implementation dependent. Most
compilers allow you to specify whether it is signed or unsigned by
command line options, but it is better not to rely upon that, and use
the 'signed' or 'unsigned' keywords explicitly when it matters.

In other words, you don't really need to know because if it matters you
can always force it one way or another thus:

signed char x ;

or

unsigned char x ;


Clifford

I think about many bugs may be occoured by defaults...
a simple case is when the compiler updated to newest version and the
compiler's manufacturer changed some default settins (for example,
signed to unsigned).

I always write the signed or unsigned and this much better human
readable (not need to figure out the compiler's defaults).

regards

Toth Jozsef wrote:
> a simple case is when the compiler updated to newest version and the
> compiler's manufacturer changed some default settins (for example,
> signed to unsigned).

The ISO standard is clear; only the signedness of the plain char type is
implementation dependent, other types are unambiguous - so int and long
for example are always signed.

If using a char as a character (as intended), then it seldom matters
whether it is interpreted as signed or unsigned since you would not
expect to be doing arithmetic on it (at least not arithmentic for which
the signedness matters). If using char as a small integer on the other
hand, then it is always a good idea to be explicit.

Better yet, use of of the C99 size/sign specific types declared in
<stdint.h> such as uint8_t or int8_t.


Clifford