Wenn die Größe von „long“ und „int“ auf einer Plattform gleich ist – unterscheiden sich „long“ und „int“ in irgendeiner Weise?

Wenn die Darstellung von a long int und ein int sind auf einer Plattform gleich, sind sie genau gleich? Verhalten sich die Typen auf der Plattform nach dem C-Standard in irgendeiner Weise anders?

Z.B. geht das immer:

int int_var;
long long_var;

void long_bar(long *l);
void int_bar(int *i);

void foo() 
{
    long_bar(&int_var); /* Always OK? */
    int_bar(&long_var);
}

Ich denke, die gleiche Frage gilt für short und int, wenn sie zufällig dieselbe Darstellung sind.

Die Frage tauchte auf, als diskutiert wurde, wie man a definiert int32_t-like typedef für einen eingebetteten C89-Compiler ohne stdint.h, dh as int oder long und ob es wichtig wäre.

Sie sind nicht kompatible Typen, was Sie an einem einfachen Beispiel sehen können:

int* iptr;
long* lptr = iptr; // compiler error here

Daher ist es am wichtigsten, wenn es um Zeiger auf diese Typen geht. Ebenso gibt es die “strenge Aliasing-Regel”, die diesen Code zu einem undefinierten Verhalten macht:

int i;
long* lptr = (long*)&i;
*lptr = ...;  // undefined behavior

Ein weiteres subtiles Problem ist die implizite Beförderung. Falls ja some_int + some_long dann ist der resultierende Typ dieses Ausdrucks long. Oder falls einer der Parameter unsigned ist, unsigned long. Dies liegt an der ganzzahligen Beförderung durch die üblichen arithmetischen Umrechnungen, siehe Heraufstufungsregeln für implizite Typen. Sollte die meiste Zeit keine Rolle spielen, aber Code wie dieser wird fehlschlagen: _Generic(some_int + some_long, int: stuff() ) da es keine gibt long Klausel im Ausdruck.

Im Allgemeinen sollte es beim Zuweisen von Werten zwischen Typen keine Probleme geben. Im Falle von uint32_tes spielt keine Rolle, welcher Art es entspricht, denn Sie sollten behandeln uint32_t sowieso als eigenständige Art. Ich würde wählen long für die Kompatibilität mit kleinen Mikrocontrollern, wo typedef unsigned int uint32_t; wird brechen. (Und offensichtlich typedef signed long int32_t; für das vorzeichenbehaftete Äquivalent.)

Die Typen long und int haben verschiedene Ränge. Der Rang des Typs long ist höher als der Rang des Typs int. Also in einem binären Ausdruck, wo ein Objekt des Typs verwendet wird long und ein Objekt des Typs int der letzte wird immer in den Typ konvertiert long.

Vergleichen Sie die folgenden Codeausschnitte.

int x = 0;
unsigned int y = 0;

die Art des Ausdrucks x + y ist unsigned int.

long x = 0;
unsigned int y = 0;

die Art des Ausdrucks x + y ist unsigned long (aufgrund der üblichen arithmetischen Umrechnungen) vorausgesetzt sizeof( int ) ist gleich sizeof( long).

Dies ist in C++ sehr wichtig als in C, wo das Überladen von Funktionen erlaubt ist.

In C müssen Sie dies beispielsweise berücksichtigen, wenn Sie I/O-Funktionen wie zum Beispiel verwenden printf um einen korrekten Konvertierungsbezeichner anzugeben.

Auch auf Plattformen wo long und int die gleiche Darstellung haben, würde der Standard es Compilern ermöglichen, absichtlich blind gegenüber der Möglichkeit zu sein, dass der Vorgang des Speicherns eines Werts in a long* könnte den Wert von an beeinflussen int* oder umgekehrt. Angesichts so etwas wie:

#include <stdint.h>

void store_to_int32(void *p, int index)
{
    ((int32_t*)p)[index] = 2;
}
int array1[10];
int test1(int index)
{
    array1[0] = 1;
    store_to_int32(array1, index);
    return array1[0];
}
long array2[10];
long test2(int index)
{
    array2[0] = 1;
    store_to_int32(array2, index);
    return array2[0];
}

Die 32-Bit-ARM-Version von gcc wird behandelt int32_t wie synonym mit long und ignorieren Sie die Möglichkeit, dass die Adresse von an übergeben wird array1 zu store_to_int32 könnte dazu führen, dass das erste Element dieses Arrays geschrieben wird, und die 32-Bit-Version von clang behandelt int32_t wie synonym mit int und ignorieren Sie die Möglichkeit, dass die Adresse übergeben wird array2 zu store_to_int32 kann dazu führen, dass das erste Element dieses Arrays geschrieben wird.

Natürlich würde nichts im Standard Compilern verbieten, sich auf diese Weise zu verhalten, aber ich denke, das Versäumnis des Standards, eine solche Blindheit zu verbieten, ergibt sich aus dem Grundsatz “je dümmer etwas wäre, desto weniger Notwendigkeit sollte es verbieten”.