Wie erkenne ich Endianess auf einem System, auf dem alle primitiven Integer-Größen gleich sind?

Question

(Diese Frage kam aus die Details CHAR_BIT erklären, sizeof und endianness jemand gestern. Es völlig hypothetisch ist.)

Lasst uns sagen, dass ich auf einer Plattform bin, wo CHAR_BIT 32 ist, so sizeof (char) = = sizeof (kurz) == sizeof (int) == sizeof (lang). Ich glaube, dass dies immer noch eine standardkonforme Umgebung ist.

Der üblicher Weg endianness zur Laufzeit (because there is no reliable way to do it at compile time) zu erkennen ist, ein union { int i, char c[sizeof(int)] } x; x.i = 1 zu machen und sehen, ob x.c[0] oder x.c[sizeof(int)-1] eingestellt wurde.

Aber das funktioniert nicht auf dieser Plattform, da ich am Ende mit einem char [1] enden.

Gibt es eine Möglichkeit zu erkennen, ob eine solche Plattform zur Laufzeit big-endian oder little-endian ist? Offensichtlich spielt es in diesem hypothetischen System keine Rolle, aber man kann sich vorstellen, dass es in eine Datei schreibt oder in eine Art Speicherbereich, die von einer anderen Maschine entsprechend ihrem (gesünderen) Speichermodell gelesen und rekonstruiert wird.

Answer 1

Das Konzept der endianness macht nur Sinn für skalare Typen von mehreren Bytes dargestellt. Per Definition ist ein char Einzelbyte, so dass jeder ganzzahlige Typ mit der gleichen Größe wie char keine Endianness hat.

Denken Sie auch daran, dass die Endianness für verschiedene Typen unterschiedlich sein kann: Zum Beispiel ist der PDP-11 eine Little-Endian-16-Bit-Architektur und 32-Bit-Integer werden aus zwei 16-Bit-Little-Endian-Werten gebildet , endet gemischt Endian.

Answer 2

Ich nehme an, die Frage läuft auf: Ist Endianess sogar ein sinnvolles Konzept auf dieser Plattform, d. H. Hat es einen nachweisbaren Einfluss auf das Verhalten eines Programms?

Ist dies nicht der Fall, dann ist Endianness (dh die Reihenfolge, in der die einzelnen Bytes einer 32-Bit-Menge gespeichert werden) lediglich ein Implementierungsdetail, das Sie nicht erkennen können, aber nicht benötigen dich auch nicht kümmern.

Wenn Endianness einen nachweisbaren Einfluss auf das Verhalten eines bestimmten Aspekts der Sprache hat ... nun, dann konstruiere einen Test, der auf diesem Verhalten basiert. Hier einige Beispiele:

• Wie funktioniert das Adressierungssystem auf der Plattform? Wenn Sie eine Adresse um eins erhöhen, wie viele Bits entspricht das? Wenn die Antwort acht Bits beträgt und das System Ihnen erlaubt, Adressen zu lesen, die kein Vielfaches von vier sind, können Sie einen Zeiger um ein einzelnes Byte vorwärts bewegen (über einen Umweg zu intptr_t) und auf diese Weise auf Endianess testen. (Ja, das ist implementationsdefiniertes Verhalten, aber es wird auch eine Union verwendet, um sowohl auf Endianess als auch auf das gesamte Konzept der Endianz im Allgemeinen zu testen.) Wenn jedoch die kleinste adressierbare Speichereinheit 32 Bytes ist, dann können Sie t teste auf diese Weise nach endianess.

• Hat die Plattform einen 64-Bit-Datentyp (a long long)? Dann können Sie eine Vereinigung von long long und zwei int s erstellen und daraus Ihren Endianness-Test erstellen.

Answer 3

Hypothetisch, in einer Umgebung, in der alle Datentypen die gleiche Größe haben, gibt es keine Endianess.

kann ich drei Möglichkeiten für Sie sehen:

• Wenn die Beschränkung nur durch C-Compiler gegeben ist und technisch die Plattform hat einige kleinere Datentypen können Sie Assembler verwenden Endianess zu erkennen.

• Wenn die Plattform den doppelten Datentyp unterstützt, können Sie damit die Endanfälligkeit erkennen, da sie immer 64 Bit breit ist.

• Sie können auch Daten in die Datei schreiben, wie Sie vorgeschlagen haben, und dann zurückgelesen. Schreiben Sie einfach zwei Zeichen (Datei im Binärmodus), verschieben Sie den Dateizeiger auf Position 1 und lesen Sie ein Zeichen zurück.

Answer 4

Struktur bitfields sollte noch richtig auf jeder Plattform arbeiten, auch diese ein:

union { 
    int i; 
    struct { 
     int b1 : 8; 
     int b2 : 8; 
     int b3 : 8; 
     int b4 : 8; 
    } s; 
} u; 

u.i = 1; 
if (u.s.b1 != 0) 
    .... 

Answer 5

Wenn Ihr Code darauf angewiesen ist zu wissen, ob Architektur BE oder LE ist, dann sollte Ihr Code eine Sicherheit haben und nicht für unbekannte Plattform kompilieren. Einige #if ! defined(ARCH_IS_LE) && ! defined(ARCH_IS_BE) \ #error unknown architecture sollten tun.

Answer 6

Die Frage bietet nicht genug Informationen, aber w/was es bietet, würde ich sagen: nicht möglich.

Answer 7

htonl sollte funktionieren:

if(htonl(1)==1) { 
    /* network order (big-endian) */ 
} else { 
    /* little-endian */ 
} 

(ich keinen Grund sieht, kann nicht htonl und Freunde in der üblichen Weise zu implementieren, auch für diese lästigen hypothetischen System - obwohl ich nicht sicher bin, wie viel helfen sie würden sich in der Praxis erweisen.)

Answer 8

Sie könnten die betreffende Variable verschieben und sehen, von welchem ​​Ende die 1 verschiebt.