 <p><code>char</code> isn’t special in this regard (besides its implementation-defined signedness), all conversions to signed types usually exhibit this “cyclic nature”. However, there are undefined and implementation-defined aspects of signed overflow, so be careful when doing such things.</p> <p>What happens here:</p> <p>In the expression</p> <pre><code>c=c+10 </code></pre> <p>the operands of <code>+</code> are subject to the <em>usual arithmetic conversions</em>. They include <em>integer promotion</em>, which converts all values to <code>int</code> if all values of their type can be represented as an <code>int</code>. This means, the left operand of <code>+</code> (<code>c</code>) is converted to an <code>int</code> (an <code>int</code> can hold every <code>char</code> value<sup>1)</sup>). The result of the addition has type <code>int</code>. The assignment implicitly converts this value to a <code>char</code>, which happens to be signed on your platform. An (8-bit) signed <code>char</code> cannot hold the value 135 so it is converted in an implementation-defined way <sup>2)</sup>. For <a href="https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation" rel="nofollow">gcc</a>:</p> <blockquote> <p>For conversion to a type of width <strong>N</strong>, the value is reduced modulo <strong>2<sup>N</sup></strong> to be within range of the type; no signal is raised.</p> </blockquote> <p>Your <code>char</code> has a width of <strong>8</strong>, <strong>2<sup>8</sup></strong> is <strong>256</strong>, and <strong>135 ☰ -121 mod 256</strong> (cf. e.g. <a href="https://en.wikipedia.org/wiki/Two&#39;s_complement" rel="nofollow">2’s complement on Wikipedia</a>).</p> <p>You didn’t say which compiler you use, but the behaviour should be the same for all compilers (there aren’t really any non-2’s-complement machines anymore and with 2’s complement, that’s the only reasonable signed conversion definition I can think of).</p> <p>Note, that this implementation-defined behaviour only applies to conversions, not to overflows in arbitrary expressions, so e.g.</p> <pre><code>int n = INT_MAX; n += 1; </code></pre> <p>is undefined behaviour and used for optimizations by some compilers (e.g. by optimizing such statements out), so such things should definitely be avoided.</p> <p>A third case (unrelated here, but for sake of completeness) are unsigned integer types: No overflow occurs (there are exceptions, however, e.g. bit-shifting by more than the width of the type), the result is always reduced modulo <strong>2<sup>N</sup></strong> for a type with precision <strong>N</strong>.</p> <p>Related:</p> <ul> <li><a href="http://stackoverflow.com/questions/24156897/a-simple-c-program-output-is-not-as-expected">A simple C program output is not as expected</a></li> <li><a href="http://stackoverflow.com/questions/4240748/allowing-signed-integer-overflows-in-c-c">Allowing signed integer overflows in C/C++</a></li> </ul> <hr> <p><sup>1</sup> At least for 8-bit <code>char</code>s, signed <code>char</code>s, or <code>int</code>s with higher precision than <code>char</code>, so virtually always.</p> <p><sup>2</sup> The C standard says (C99 and C11 (n1570) 6.3.1.3 p.3) “[…] either the result is implementation-defined or an implementation-defined signal is raised.” I don’t know of any implementation raising a signal in this case. But it’s probably better not to rely on that conversion without reading the compiler documentation.</p>