IntToStr bereitet Probleme beim umstieg auf Delphi 12

[Kishmet]

Guten Morgen zusammen,

wir haben es nun endlich geschafft auf Delphi 12 umzusteigen, leider stehe ich grade vor einem seltsamen "Fehler(?)".

In Delphi 11 hat noch alles getan in Delphi 12 wirft folgender Ausdruck leider einen Fehler (Fehler bei der Bereichsprüfung):

Code:

IntToStr($FFFFFFFFFFFFFFFF);

(Das sind 16 F -> also -1).

Sobald ich folgendes schreibe, geht es witzigerweise. (Das sind nur 15 F)

Code:

IntToStr($FFFFFFFFFFFFFFF);

Vermutlich eine wichtige Info:
Wir Compilieren diese Software als 32bit.

Hat jemand eine Idee woran das liegt? Natürlich ist das oben nur ein (sinnloses aber sehr einfach nachzuvollziehendes) Beispiel.

Vielen lieben Dank fürs Lesen, über Hinweise was sich geändert hat wäre ich super dankbar.

Abhilfe schafft übrigens:

Code:

IntToStr(Integer($FFFFFFFFFFFFFFFF));

Das ist für uns aber eher nicht zielführend, daher würde ich gerne ernsthaft verstehen was los ist um die beste mögliche Lösung zu finden.

[Bernhard Geyer]

$FFFFFFFFFFFFFFFF wird vermutlich jetzt als UInt interpretiert
D.h. mit einem expliziten Cast sollte es gehen:

Delphi-Quellcode:

IntToStr(Integer($FFFFFFFFFFFFFFFF));

[Delphi.Narium]

Nur 'ne Vermutung?

Was ergibt $FFFFFFFFFFFFFFFF als Dezimalzahl?
Was ergibt $FFFFFFFFFFFFFFF als Dezimalzahl?

Welchen Dezimalzahlbereich deckt Integer unter 32 Bit ab?

7FFFFFFF (hex) = 2.147.483.647 (dezimal)
80000000 (hex) = -2.147.483.648 (dezimal)

Damit dürften die verwendeten Werte für 32-Bit deutlich zu hoch sein.

Für 64-Bit sind diese Werte

Maximalwert: 7FFFFFFFFFFFFFFF (hex) = 9.223.372.036.854.775.807
Minimalwert: 8000000000000000 (hex) = -9.223.372.036.854.775.808

Demnach sind $FFFFFFFFFFFFFFFF einfach $8000000000000000 zuviel,
in Dezimal entspricht das 92.233.720.368.54.775.808, das ist schon eine ziemlich große Menge (Faktor 10) ;-)

Letztlich liegt $FFFFFFFFFFFFFFFF schlicht und einfach außerhalb des für Integer gültigen Bereiches und damit ist die Fehlermeldung "Fehler bei der Bereichsprüfung" absolut korrekt.

[Kishmet]

Hallo Bernhard,

ok, das könnte sein. Wüsstest du wo ich eine Änderungsnotiz finden könnte, falls es eine gibt? Ich werde einfach nicht fündig diesbezüglich...

Hallo Delphi.Narium,

für mich auch absolut einleuchtend (nachdem ich kurz gebraucht habe um zu verstehen was du da erklärt hast - vielen Dank dafür!) warum tritt das dann aber jetzt erst mit Delphi 12 auf und war vorher nie ein Thema? Wo liegt die Änderung?

Bisher hat der Wert $FFFF FFFF FFF FFFF einfach -1 ergeben... jetzt erzeugt er den Überlauf... du hast absolut recht, aber trotzdem hat sich etwas verändert und ich würde gerne wissen was :oops::shock::?:

[Delphi.Narium]

Einmal die Bereichsprüfung beim Kompilieren eingeschaltet, einmal ausgeschaltet.

[Kishmet]

In beiden Versionen ist der Code der Funktion IntToStr der Gleiche, auch drumherum:

Code:

{$IFOPT Q+}
  {$DEFINE __OVERFLOWCHECKS}
  {$OVERFLOWCHECKS OFF}
{$ENDIF}
function IntToStr(Value: Integer): string;
begin
  Result := _IntToStr32(Abs(Value), Value < 0);
end;

function IntToStr(Value: Int64): string;
begin
  Result := _IntToStr64(Abs(Value), Value < 0);
end;
{$IFDEF __OVERFLOWCHECKS}
  {$UNDEF __OVERFLOWCHECKS}
  {$OVERFLOWCHECKS ON}
{$ENDIF}

Sprich es hat sich nichts verändert. Das Verhalten tritt auch bei absolut neuen leeren Projekten auf die nichts anderes enthalten als:

Code:

ShowMessage(IntToStr($FFFFFFFFFFFFFFFF));

Oder möchtest du mir mitteilen das sich das auch tatsächlich Verändert hat? Falls ja, wo finde ich die passende Releasenote?

[Blup]

Die Konstante $FFFFFFFFFFFFFFF ist untypisiert und wird als (2^64 -1) interpretiert.

IntToStr() ist für Integer und Int64 deklariert.
Da ist die Meldung schon richtig.

Hier ist auch eine Typumwandlung notwendig:

Delphi-Quellcode:

const
  i: Integer = Integer($FFFFFFFF);
  i64: Int64 = Int64($FFFFFFFFFFFFFFFF);

Das ist übriegens die Überlaufprüfung, nicht die Bereichsprüfung.

[Kishmet]

Hi Blup,

Ja, habe ich auch grade festgestellt... und auch das an der besagten Stelle an der mein Problem auftaucht tatsächlich folgendes gemacht wird:

Code:

IntToStr(Meine_uInt64_Variable)

Aber uInt64 kann IntToStr gar nicht. Gibt es hier eine schlaue Lösung für? Denn Integer(Variable) ist an der Stelle ja einfach Falsch, oder? Und meine Frage bleibt tatsächlich bestehen... was genau hat sich geändert das es jetzt plötzlich Auswirkungen hat?

[Blup]

Die Funktion ist überladen:

function IntToStr(Value: Integer): string;
function IntToStr(Value: Int64): string;

Int64() wäre dann die richtige Umwandlung.

[Kishmet]

Aber auch int64(Meine_uInt64_var) könnte durchaus Informationsverlust bedeuten, oder übersehe ich gerade etwas?

[Kishmet]

Eigentlich ist das alles Schmutz weil es schlicht und ergreifend ein Fehler im Code ist und schon immer war... IntToStr, war schon immer die falsche Funktion an dieser Stelle. Mal schauen was für Fehler das jetzt nach sich zieht.

Mich würde immernoch interessieren was sich genau verändert hat, das dieser Fehler jetzt auftritt und vorher einfach ignoriert wurde, aber am Ende des Tages ist das egal.

Vielen lieben dank euch!

[Blup]

Nur wenn du tatsächlich Werte ab 2^63 oder größer hast.
Diese werden dann als negative Zahlen ausgegeben.
Also keine Verlust, eher eine Verfälschung.

[Delphi.Narium]

Ist denn in beiden Delphi die Bereichsprüfung eingeschaltet? (Kompileroptionen vergleichen.)

Alternativ im Quelltext:

Delphi-Quellcode:

{$R-}
// Hier der Code, der den Fehler verursacht
{$R+} // Optional: Reaktivieren der Bereichsprüfung am Ende

Zitat:

Zitat von Blup (Beitrag 1545031)

Die Funktion ist überladen:

function IntToStr(Value: Integer): string;
function IntToStr(Value: Int64): string;

Int64() wäre dann die richtige Umwandlung.

$FFFFFFFFFFFFFFFF (16 F) sind aber auch für Int64 zuviel.

[Kishmet]

@delphi.narium : Ja es hat sich nichts weiter verändert. Wenn dann eine Grundeinstellung irgendwo im Compiler (Also von RAD Studio selbst eine Defaulteinstellung die von 11 auf 12 geändert wurde) von der ich so nichts weiß. Alles andere (Sprich Code und Projekteinstellungen) ist identisch, wie gesagt auch mit neuen Projekten passiert genau das gleiche.

[Delphi.Narium]

Wenn die Bereichsprüfung in beiden Delphi an ist, dann müsste sie auch bei Delphi 11 den Fehler verursachen.

In dem Fall wäre mein Rückschluss: In Delphi 12 wurde ein Fehler behoben, der in Delphi 11 noch auftrat.

[Uwe Raabe]

Für UInt32/Cardinal bzw. UInt64 gibt es übrigens UIntToStr.

[Kishmet]

@Uwe Raabe: Das ist der Weg. Werden wir jetzt auch so machen. Die Stelle ist wohl so, das wir hier bisher nicht wirklich einen ernstzunehmenden Fehler sondern eher nur einen Darstellungsfehler kreiert haben. :roll:

@delphi.narium: Was mich daran so nervt, ist das ich nirgends in den Releasenotes von Delphi irgendetwas dazu finde. Egal wo ich schaue, ich finde keinen Hinweis darauf das etwas repariert oder geändert worden ist, was dieses Verhalten erklären würde.

Euch allen Danke für die Hilfe!

[Delphi.Narium]

Vielleicht ist dies keine bewusste Fehlerkorrektur sondern ein Nebeneffekt anderer Änderungen am Compiler.

Sprich: Der Fehler war nicht bekannt und wurde versehentlich behoben? ;-)

[Blup]

Wie bereits geschrieben es ist die Überlaufprüfung, nicht die Bereichsprüfung.
Delphi2007 gibt mit aktiver Überlaufprüfung ebenfalls einen Fehler aus.

[Rolf Frei]

Das Problem ist einfach nur, dass beim Upgrade deiner D11 Projekte die Projekt-Einstrellugnen verändert wurden. War bei mir auch so. Habe dann einfach in den Projekt-Einstellugnen die Bereichs- und Überflussüberprüfung deaktiviert, damit diese gleich eingegstellt sind wie bei D11. Am Compiler wurde mMn nichts geändert, sondern einfach die Vorgabeprojekteinstellungen verändert. Aber wie schon geschrieben, war dein Code so eben nicht korrekt und würde mit eingeschaltetem Range oder Overflow Check auch unter D11 einen Fehler bringen.

Neu sind in den Projektoptionen (in englischem Delphi) unter Building/Delphi Compiler/Compiling alle Einträge unter "Runtime Errors" eingeschaltet, wo hingegen bis D11 nur der I/O Check aktiv war. Einfach die beiden anderen Check deaktivieren und alles sollte wieder so wie in D11 laufen.

[Rollo62]

Deswegen und aus anderen Gründen versuche ich möglichst alle diese "Magic numbers" aus dem Code zu verdammen und mit sinnvollen Namen zu versehen, so wie das schon Blup vorgeschlagen hat:

Delphi-Quellcode:

const
  CMyInt   : Integer = Integer($FFFFFFFF );
  CMyInt32 : Int32   = Int32(  $FFFFFFFF );
  CMyInt64 : Int64   = Int64(  $FFFFFFFFFFFFFFFF );

[freimatz]

:thumb:

[Kishmet]

Zitat:

Zitat von Rolf Frei (Beitrag 1545046)

Das Problem ist einfach nur, dass beim Upgrade deiner D11 Projekte die Projekt-Einstrellugnen verändert wurden. War bei mir auch so. Habe dann einfach in den Projekt-Einstellugnen die Bereichs- und Überflussüberprüfung deaktiviert, damit diese gleich eingegstellt sind wie bei D11. Am Compiler wurde mMn nichts geändert, sondern einfach die Vorgabeprojekteinstellungen verändert. Aber wie schon geschrieben, war dein Code so eben nicht korrekt und würde mit eingeschaltetem Range oder Overflow Check auch unter D11 einen Fehler bringen.

Neu sind in den Projektoptionen (in englischem Delphi) unter Building/Delphi Compiler/Compiling alle Einträge unter "Runtime Errors" eingeschaltet, wo hingegen bis D11 nur der I/O Check aktiv war. Einfach die beiden anderen Check deaktivieren und alles sollte wieder so wie in D11 laufen.

DANKE! Das war die Info die ich gesucht habe! Vielen Dank!

@Rollo62: Bei uns im Code werden an der Stelle keine Magicnumbers genutzt, sondern von einem Speicher Daten gelesen, daher ist das keine Hilfe, würde auch in meinen Augen keinen Fehler beheben. Da unsere Variablen/Konstanten dann ja auch schon immer Flasch gesetzt gewesen wären und es bisher nicht aufgefallen wäre. Aber im großen und ganzen Stimme ich dir zu! Keine Magic numbers wenn möglich.