Nevím jestli to je riziko tady, ale kompilátory Cčka jsou poslední dobou kreativní v optimalizaci a není dobré je provokovat nedefinovaným chováním - namátkou https://www.airs.com/blog/archives/120, ale řešilo se to i na lwn (https://lwn.net/Articles/442668/) a jinde.
Davneji jsem videl celkem zajimave video na tohle tema, ale nevim ktere to bylo:
https://www.youtube.com/results?search_query=undefined++behavior+cpp
Podle me by se nemelo resit to nedefinovane chovani, protoze pokud uz se tam dostanete, tak vase vypocetni modely jsou spatne, a spolehat na urcity zpusob implementace preteceni neni uplne hodno dobreho programatora. Jiste, v ASM se delali ruzne hacky.. ale c/cpp uz je jazyk vyssi urovne a bylo by vhodne se drzet typu ktere pojmou data vlastniho algoritmu, pripadne ty data osetrovat - treba v GPU / grafice je velice casto uzivana funkce clamp(), aby zustali data v nejakem rozsahu (napr. 0..1)
No, jsou procesory, ktere jsou plne 32bit (treba DSP) - tj. nemaji vubec vyvedeny signal A0 a A1 adresove zbernice!
V C-cku tam samozrejme plati ze sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) - ale zde na tomto procesoru je to vzdy 1 (ale 32 bitu).
Kdyz si tady do promenne typu char ulozite treba jeden milion, tak ho tam pri cteni zase najdete :-)
Takze takove to spolehani se na implicitni orezavani hodnot se vam muze pekne vymsttit ......
A nebo takova dalsi prasarna jako pretypovavani hodnoty typu int na ukazatel na char zde taky nefunguje .....