If an integer is signed by default, why does the signed keyword exist?

Question

I'm curious why the signed keyword exists because I believe most integers and other variables are signed by default. Putting the signed keyword before int virtually does nothing. What is it used for, and why does it exist?

Rumba

If you have an unsigned value to start, you may wish to force a signed value during calculation (e.g.) unsigned int x = 0xFFFFFFFF; int y = 7; x = ((signed) x) + y; There are other [probably better] examples. – Pinna

Even when it is a no-op, it's not "doing nothing": it's communicating the programmer's intent. – Firth

@CraigEstey I believe (signed) is equivalent to (int) ? – Engender

Even more curious is the auto keyword. I cannot think of an example where it is necessary in C. (answer here: https://mcmap.net/q/173560/-why-does-auto-a-1-compile-in-c ) – Fishing

Note that auto does have a use, infers an unspecified type from the variable's usage, in modern C++. – Molnar

@Fishing note that this is tagged as both C and C++, and imho this is a case where that is fine, but auto is very different in C and C++ – Kulda

@EugeneSh. I.A.N.A.L.L but I think that signed by itself says convert the base type to signed (e.g. unsigned int --> int but unsigned long long --> long long). What' more common is the reverse: int x; (unsigned) x ... I think there was a question recently from P__J about UB and signedness that clarified this #64899837 – Pinna

@CraigEstey: I'm afraid casting an unsigned long long as (signed) converts it to an int, not a long long. – Fishing

@Fishing After rereading the link I was referring to, it doesn't seem to cover casting, only unary - – Pinna

Answer 1

There are at least two places where the signed keyword is not a no-op:

• With char: the signedness of "plain" char is implementation-defined. On implementations where it's an unsigned type, signed char is needed to get the signed variant. Even if char is a signed type, signed char, char, and unsigned char are all distinct types.

• With bitfields: bitfield members without explicit signedness have implementation-defined signedness. For example, in

  struct foo {
      int b:1;
  };
  

  the range of values of b may be { -1, 0 } or { 0, 1 } depending on the implementation. If you want to be sure you get the signed version, you need the signed keyword. Note that while the standard is not very clear on this, on popular implementations, this applies to typedef too: if the bitfield member uses a typedef-defined type that doesn't include explicit signedness, the implementation-defined signedness (on GCC, set by -fsigned-bitfields) applies there too. This means types like int32_t should be defined using the signed keyword to avoid really bad surprise behavior when they're use in bitfields.

Reincarnation

Re “This means types like int32_t should be defined using the signed keyword to avoid really bad surprise behavior when they're use in bitfields”: Yikes! – Cons

Answer 2

char is either signed or unsigned, but in any case it is a type distinct from unsigned char and signed char. Those three are different types:

char
signed char
unsigned char

If not with signed there would be some other way needed to distinguish them.

Even without char. Why not? It allows to be explicit:

signed int x; // Someone decided that x 
              // must be signed
int y;        // Did the author choose signed 
              // consciously? We cannot tell.

Kulda

signed int x; // Someone copy-pasted the declaration from somewhere and was too scared to remove the magic signed keyword – Stereography

@Stereography meh I agree with your point, but there is cargo cult everywhere, thats no reason to try to write code that actually means what it says ;) – Kulda