Ein weiteres Beispiel sind die Shift-Operationen. Die Funktionsweise ist abhängig von der verbauten CPU. Beispiel Intel ... (was war da gleich nochmal verbaut, egal) 32bit CPU.
Code:
int8_t a = 0x01;
b = a << 8;
c = a << 32;
Auf meiner damaligen Intel CPU 32bit war b == 0 und C == 1. Das konnte ich in jeder x-beliebigen Sprache testen (C, Java, .NET, ...). Dies kann man in der Doku von Intel nachschlagen. Aber wer denkt da schon dran.
Deine Begründung ist schlicht falsch.
Ich gehe im Folgenden auf c = a << 32 ein:
C (ISO/IEC 9899:1999 (E) §6.5.7): Ist der linke Operand schmaler als int, so wird er zunächst auf int konvertiert. Dann folgt << und hier sagt die C-Norm, dass deren Verhalten undefiniert ist, falls um die Breite des (evtl. konvertierten) linken Operanden oder mehr geschoben wird. Es wäre also durchaus möglich und von der Norm aus zulässig, wenn c den Wert 42 hat, das Programm an der Stelle einen Segfault verursacht oder dein $HOME gelöscht wird. Üblicherweise wird der Übersetzer den einfachsten Weg wählen und einfach den entsprechenden Maschinenbefehl, bei x86 shl, ausgeben (wenn das ganze nicht eh schon komplett zu einer Konstante gefaltet wird).
Java (JLS 3rd Edition §15.9), .NET (wobei nicht .NET, sondern wohl eher C# und somit ECMA-334 §14.8): Diese definieren ebenfalls eine eventuelle Konversion auf mindestens int (wobei hier die Breite eines int im Gegensatz zu C exakt auf 32 Bit festgelegt ist) und danach passiert ein << um den Wert des rechten Operanden modulo der Breite des (evtl. konvertierten) linken Operanden, also quasi (int)a << (32 % 32) und somit (int)a << 0. Das hat nichts, aber auch gar nichts, mit dem zu tun, was der Prozessor implementiert (nur [mehr oder minder] zufällig verhält sich die shl-Befehl des x86 ebenso).
Es gibt auch Prozessoren, deren Schiftbefehl sich anders verhält, z.B. der PPC64.
Das Nachschlagen der genauen Semantik von b = a << 8, welche stark abhängig vom Typ von b ist, überlasse ich dem geneigten Leser als Übungsaufgabe.
