Fallendarstellung

1. Was ist eine “Trap-Darstellung” in C (einige Beispiele könnten helfen)? Gilt das für C++?

2. Angesichts dieses Codes …

   float f=3.5;
   int *pi = (int*)&f;
   

   … und davon ausgegangen sizeof(int) == sizeof(float)tun f und *pi haben die gleiche binäre Darstellung/das gleiche Muster?

1. Eine Trap-Darstellung ist ein Sammelbegriff, der von C99 (IIRC, nicht von C89) verwendet wird, um Bitmuster zu beschreiben, die in den von einem Typ belegten Raum passen, aber ein undefiniertes Verhalten auslösen, wenn sie als Wert dieses Typs verwendet werden. Die Definition befindet sich in Abschnitt 6.2.6.1p5 (mit Tentakeln in ganz 6.2.6) und ich werde sie hier nicht zitieren, weil sie lang und verwirrend ist. Von einem Typ, für den solche Bitmuster existieren, wird gesagt, dass er Trap-Darstellungen “besitzt”. Kein Typ muss irgendwelche Trap-Darstellungen haben, aber der einzige Typ, den der Standard garantiert nicht Fallendarstellungen haben ist unsigned char (6.2.6.1p5, 6.2.6.2p1).

   Der Standard gibt zwei hypothetische Beispiele für Trap-Darstellungen an, von denen keines dem entspricht, was eine echte CPU seit vielen Jahren getan hat, also werde ich Sie nicht damit verwirren. EIN gut Beispiel einer Fallendarstellung (auch die nur etwas, das auf jeder CPU, auf die Sie wahrscheinlich stoßen, als Trap-Darstellung auf Hardwareebene qualifiziert ist) ist ein signalisierendes NaN in einem Fließkommatyp. C99 Annex F (Abschnitt 2.1) lässt das Verhalten der Signalisierung von NaNs explizit undefiniert, obwohl IEC 60559 deren Verhalten detailliert spezifiziert.

   Es ist erwähnenswert, dass während Zeigertypen sind erlaubt, Trap-Darstellungen zu haben, sind Null-Zeiger nicht Falle Darstellungen. Nullzeiger verursachen nur undefiniertes Verhalten, wenn sie dereferenziert oder versetzt werden; andere Operationen auf ihnen (am wichtigsten Vergleiche und Kopien) sind genau definiert. Trap-Darstellungen verursachen undefiniertes Verhalten, wenn Sie lediglich lesen sie mit dem Typ, der die Trap-Darstellung hat. (Ob ungültig aber Nicht-Null-Zeiger werden oder sollten als Trap-Repräsentationen betrachtet werden und sind ein Gegenstand der Debatte. Die CPU behandelt sie nicht so, der Compiler jedoch möglicherweise.)

2. Der von Ihnen gezeigte Code hat ein undefiniertes Verhalten, aber das liegt an den Zeiger-Aliasing-Regeln, nicht an Trap-Darstellungen. So konvertieren Sie a float in die int mit der gleichen Darstellung (unter der Annahme, wie Sie sagen, sizeof(float) == sizeof(int))

   int extract_int(float f)
   {
       union { int i; float f; } u;
       u.f = f;
       return u.i;
   }
   

   Dieser Code hat nicht spezifiziert (nicht undefiniertes) Verhalten in C99, was im Grunde bedeutet, dass der Standard nicht definiert welchen ganzzahligen Wert wird produziert, aber Sie bekommen etwas gültiger ganzzahliger Wert, es ist keine Trap-Darstellung, und der Compiler darf nicht optimieren, wenn Sie davon ausgehen, dass Sie dies nicht getan haben. (Abschnitt 6.2.6.1, Abs. 7. Meine Kopie von C99 enthält möglicherweise technische Berichtigungen – soweit ich mich erinnere war in der Originalveröffentlichung nicht definiert, wurde aber in einem TC in nicht spezifiziert geändert.)

Undefiniertes Verhalten zum Aliasing eines Floats mit einem Pointer-to-int.

Im Allgemeinen kann jeder Nicht-Trap-IEEE-754-Gleitkommawert auf einigen Plattformen problemlos als Ganzzahl dargestellt werden. Es gibt jedoch Gleitkommawerte, die zu unerwartetem Verhalten führen können, wenn Sie davon ausgehen alle Fließkommawerte haben eine eindeutige ganzzahlige Darstellung und Sie zwingen die FPU zufällig, diesen Wert zu laden.

(Beispiel entnommen aus http://www.dmh2000.com/cpp/dswap.shtml)

Wenn Sie beispielsweise mit FP-Daten arbeiten, die zwischen CPUs mit unterschiedlicher Endianness gemarshallt werden müssen, könnten Sie Folgendes in Betracht ziehen:

double swap(double)

Wenn der Compiler die Eingabe in ein FPU-Register lädt und es sich um eine Trap-Darstellung handelt, kann die FPU sie leider mit einer äquivalenten Trap-Darstellung zurückschreiben, die zufällig eine andere Bit-Darstellung ist.

Mit anderen Worten, es gibt einige FP-Werte, die keine entsprechende Bitdarstellung haben, wenn Sie nicht richtig konvertieren (mit richtig meine ich durch a union, memcpy über char * oder andere Standardmechanismen).