Da das
int-Thema hier schon eh' breit getreten ist...
Ich hab tatsächlich oft von Problemen mit
int und
long gelesen. Ein schönes Beispiel aus dem C-Standard wurde ja bereits genannt, aber die meisten lassen sich auf zwei Sachen zurückführen: Vornherein falsch genutzte Typen (
int statt
size_t), was bei 64bit-Ports
ins Knie schießt, oder eben solche fehlgeleiteten Erwartungen, wie etwa dass
int in etwa die Größe eines GPRs haben sollte, bei x86_64 häufig dennoch nur 32bit groß ist.
Beim ersten dieser Fälle kann man natürlich sagen: Eigene Dummheit!
size_t und
intptr_t gibt es nicht umsonst. Da gegen könnte man aber wieder ins Feld führen, dass man für diese Typen erstmal einen extra Header einfügen muss. Dann kann man auch gleich
int32_t & Co. nutzen. Oder gleich solche Typen als Builtins haben.
Der zweite Fall ist einfach dumm, aber lässt sich im Grunde auf Problem 1 herunterbrechen, dass man besser Typen garantierter Größe verwendet. In solchen Fällen z.B.
intptr_t.
Insofern...
int ist für die meisten Fälle tatsächlich genau richtig, aber es ist nicht von der Hand zu weisen, dass
int "oft" falsch verwendet wird, was dann schnell zu bösen Bugs führt. Diese Verwirrung wäre in Sprachen wie Rust mit builtin Typen wie
i32 und
isize nicht passiert. Angesichts der Tatsache, dass
int auf den meisten Plattformen eh' 32bit groß ist, dass für auf Microcontroller portierbaren Code
(z.B. MRuby) eh' oft Spezialisierungen mit
#ifdefs getätigt werden, und dass diese 32bit eh' oft den Wertebereich umfassen, den man so im Alltag braucht... Wo ist das Problem dabei,
int32_t zu tippen? In den meisten Fällen ist es eh' nur ein Alias für
int, bloß mit der Garantie, dass es sich wirklich-wirklich überall völlig gleich verhält. Zumal bei der expliziten Größenangabe im Namen schnell die Alarm-Glocken läuten, wenn man für 64bit-Systeme portiert und man es irgendwo fälschlich für Größen nutzte, und dass 32bit-Arithmetik auf 64bit-Plattformen keine Performance einbüßt.