Ungewöhnliche ungültige Gleitkommaoperation

[Mikkey]

@Klaus, Himitsu, Popov, Namenloser:

Das klingt zumindest nach Wegen aus der Krise ;-), am Dienstag werde ich alle mal durchprobieren.

Was ich auf jeden Fall vermeiden muss, ist, den Fehler einfach nicht aufschlagen zu lassen, denn dann tritt er einfach später an irgendeiner Stelle auf (mit entsprechender Meldung "ungültige Gleitkommaoperation" an der Oberfläche.

[Mikkey]

Aalso:

Ich habe aufgrund der Tipps einiges durchprobiert: der Code sieht so aus (auskommentierte Varianten wurden entsprechend probiert):

Delphi-Quellcode:

class function TdlgKlimaSetup.DateTimeToEdit(value: TDateTime): String;
var
  P: PByte;     //H
  i: Integer;
  S: string;
  cmp: Double;  //P
  w8087: Word; //N
begin
  try
    w8087 := Get8087CW(); //N
    cmp := 0.1;
    //if IsNaN(value) or (CompareDateTime(value, cmp) = LessThanValue) then //K
    if value <= cmp then //P
      result := ''
    else
      result := DateTimeToStr(value);
  except
    on E: Exception do begin //H
      P := @value;
      for i := 0 to 7 do
        try
          S := S + IntToHex(P^, 2);
          Inc(P);
        except
          S := S + '**';
        end;
      ShowMessage(Format('ungültige Zahl: "%s" - %s - CW8087=%x', [S, E.Message, w8087]));//HN
    result := '';
    end;
  end;
end;

@Popov:
Auch der Vergleich mit der Variablen hat denselben Effekt. Die Einstellungen sind diese:

Delphi-Quellcode:

A=8 B=0 C=0  D=1 E=0  F=0 G=1 H=1 I=1 J=0 K=0 L=1 M=0 N=1 O=1 P=1 Q=0 R=0 S=0 T=0 U=0 V=1 W=0 X=1 Y=2 Z=1

@Himitsu:
Der Effekt ist derselbe, die Messagebox hängt als Grafik an

@Klaus:
Auch mit CompareDateTime wird dieselbe Exception ausgelöst.

@Namenloser:
Das ausgelesene Control Word ist $1372 (habe ich in der Messagebox mit ausgegeben).
Der Assembercode ist als Grafik wiedergegeben (copy/Paste klappt aus dem CPU-Fenster nicht). Ein Einzelschritt über den FLD von der markierten Stelle führt bereits nach "ntdll.KiUserExceptionDispatcher".

Beim Schreiben ist mir noch eine weitere Idee gekommen:
An den Anfang des Codes habe ich folgendes eingefügt:

Delphi-Quellcode:

    cmp := 0.1;
    Try
    if cmp < 0 then
      cmp := 0.2;
    except
      ShowMessage('Totaler Unsinn');
    end;

Damit erscheint diese Message-Box, aber der übrige Code läuft dann ohne Exception durch. :roll:
Jetzt hoffe ich noch, dass das CW etwas Hilfreiches aussagt.

[Mikkey]

Vielen Dank für die Unterstützung.

Zwar weiß ich immer noch nicht, warum der Fehler sich auf diese Weise bemerkbar macht, aber ich habe den Auslöser gefunden.
Zunächst hatte ich mit einer Codezeile, die den Fehler provoziert, die Stelle gesucht, die den Zustand herbeiführt.
Hier wurde eine mit NaN initialisierte Variable mit =0 verglichen.
Nachdem die Variable zuätzlich gegen NaN verglichen wird, tritt der nachfolgende Fehler nicht mehr auf.

Keine Ahnung, warum nicht bereits beim ersten Vergleich eine Exception fliegt, in der Hilfe steht lediglich:

Zitat:

Verwenden Sie NaN nicht in Vergleichsoperationen

[Klaus01]

.. es tut mit leid, aber der code wirft keine Exception..

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  value: TDateTime;
  cmp: double;
  w8087: word;
begin
  try
    w8087 := get8087cw;
    value := strToFloat(Edit1.Text);
    cmp := 0.1;
    if value <= cmp then
      edit2.Text := 'less than 0.1 or equal to 0.1'
    else
      edit2.Text := DateTimeToStr(value);
  except
    on E:Exception do
      showMessage(E.Message);
  end;
end;

aber wenn Du schon den Übeltäter gefunden hast..

Grüße
Klaus

[Mikkey]

Der müsste auch eher so ausschauen:

Delphi-Quellcode:

var
  value: TDateTime;
  cmp: double;
  w8087: word;
begin
  try
    cmp := NaN;
    if cmp = 0 then cmp := 0;
    cmp := 0.1;
    value := 0;
    if value <= cmp then // hier müsste die Exception fliegen
      edit2.Text := 'less than 0.1 or equal to 0.1'
    else
      edit2.Text := DateTimeToStr(value);
  except
    on E:Exception do
      showMessage(E.Message);
  end;
end;

[Sherlock]

Ich würde gerne meinen Senf dazu geben, trotzdem oder weil die Sache aufgelöst wurde.
Ich vergleiche seit vielen Jahren Datumsfelder, bzw. prüfe, ob ein DateTime gefüllt/gesetzt ist. Noch nie ist mir sowas passiert. Vermutlich liegt es an meiner Unkenntnis von NaN (Ignorance is bliss). Ein DateTime behandle ich immer als DateTime. Einzig eine gelegentliche Abfrage auf

Delphi-Quellcode:

>0

zum prüfen, ob das Ding gefüllt ist (bei mir gibts Gottlob keine Ereignisse vor 1900) erlaube ich mir, und bin noch nie in ein derartiges Problem gelaufen. Mir ist ehrlich gesagt immer noch unklar, was bei Dir eigentlich warum falsch gelaufen ist. Die Geschichte mit dem NaN würde aber an oberster Stelle auf der kurzen Liste der Verdächtigen stehen...wegen KISS und so ;)

Sherlock

[Mikkey]

@ Sherlock:
Was würdest Du dann für eine Repräsentation von "nicht vorhanden" in einem Double-Wert verwenden, der als gültiger Wert beispielsweise zwischen -1E6 und 1E6 liegen kann. Früher wurde in dem System so etwas wie 1E32 dafür verwendet, was sich aber als besch^^^^^ungünstig herausgestellt hat.

[Sherlock]

Wie gesagt, ich bin in der glücklichen Situation kein Datum vor 1900 berücksichtigen zu müssen. Ich weiss ja nicht, was Du für eine Anwendung damit betreiben musst, aber bist Du sicher, daß das für Dich nicht gilt?

Sherlock

[Mikkey]

@ Sherlock:

Zitat:

Zitat von Mikkey (Beitrag 1256450)

Was würdest Du dann für eine Repräsentation von "nicht vorhanden" in einem Double-Wert verwenden, ...

Es geht nicht um das Date/Time-Feld, das könnte ich sogar als ungültig betrachten, wenn es unter 41000 liegt.
Der Fehler entsteht durch Vergleich eines Double (enthaltend NAN) mit 0.

[Medium]

Wenn mich nicht alles täuscht, werden bei Operationen mit NaNs (ja, Mehrzahl. Es gibt viele verschiedenen NaNs, die teils auch unterschiedliche Dinge besagen) in der FPU Flags verwendet, die ansonsten nicht mitspielen. Eventuell ist hier bei deinem Vergleich vorher ein solches gesetzt worden, da man aber dokumentiert hat, dass Vergleichen mit NaN böse ist, wird ggf. nicht mehr weiter auf diese geprüft. Bei nachfolgenden FP Operationen könnte dieses Flag dann zum Knall führen.
Wenn das so zutrifft (ich kann es im Moment nicht wirklich testen), dann finde ich einen kleinen Hinweis in der Doku für zu wenig. Da sollte dann eigentlich auch der Compiler mit einer Meldung kommen, wenn das Kompilat den Fall nicht anderweitig sauber behandelt.