Argument außerhalb des gültigen Bereichs (for-Schleife zählt ins Minus)

[SneakyBagels]

Ich bekomme leider seit einiger Zeit oben genannte Fehlermeldung aber nur im 64bit-Kompilat.

Die Meldung kommt an einer Stelle an der ich auf das property einer generischen TObjectListe zugreife.
32bit wie gesagt absolut kein Problem und das hier ist eine absolute Standardzeile nicht einmal die Mühe wert sie hier einzufügen.
Wäre es etwas sehr Ernstes müsste es ja auch im 32bit-Kompilat auftauchen.

Ein kleiner Test hat gerade gezeigt, dass meine Schleife bis mindestens -1 zählt obwohl bei 0 Schluss sein sollte!

Delphi-Quellcode:

 for i := cList.Count - 1 downto 0 do
  begin
   IntToStr(i));

Wie kann das sein?

Edit: Problem wurde erledigt. Seite 5 Beitrag 41 http://www.delphipraxis.net/1371259-post41.html

[zeras]

Lass dir doch einmal vor der Schleife den Wert von

Delphi-Quellcode:

cList.Count

anzeigen.
Nicht das der vorher schon negativ ist.
Oder zeige in jeder Schleife den Wert an.
Ich glaube hier kaum, dass es bei einer solch einfachen Funktion ein Problem geben sollte.
Ist vielleicht deine Liste leer?

[SneakyBagels]

Delphi-Quellcode:

for i := cList.Count - 1 downto 0 do

Ich der Startwert von Count ist 8.

[nahpets]

Delphi-Quellcode:

if cList.Count > 0 then 
begin
  for i := cList.Count - 1 downto 0 do
  begin
    IntToStr(i)); 
  end;
end else begin
  Meldung leere Liste
end;

Wobei mich bei einer leeren Liste schon interessieren würde, ob bei einem

Delphi-Quellcode:

for i := -1 downto 0 do
begin
  ShowMessage('Diese Meldung zu sehen ist.');
end;

[SneakyBagels]

Die Liste ist befüllt und hat 8 Einträge.
Die Zählung beginnt bei 8 und soll bei 0 aufhören (downto 0). Geht aber ins Minus.

[gammatester]

Zitat:

Zitat von SneakyBagels (Beitrag 1371178)

Die Liste ist befüllt und hat 8 Einträge.
Die Zählung beginnt bei 8 und soll bei 0 aufhören (downto 0). Geht aber ins Minus.

Laut Code sollte die Zählung bei 8 Elementen doch bei 7 beginnen:?:

[SneakyBagels]

Folgende Testdaten sind vorhanden
Datei1.txt bis Datei8.txt

Eine Showmessage vor der Schleife zeigt "Count: 8".
Eine Showmessage in der Schleife zeigt "i = 7".... bis "i = 0" und dann geht es noch weiter runter bis -1.

Nothilfe schafft aktuell

Delphi-Quellcode:

if i < 0 then Break;

Das ist aber nur bei 64bit nicht bei 32bit.

[nahpets]

Bleibt der Fehler auch, wenn Du das mal so abänderst?

Delphi-Quellcode:

var
  Anzahl : Integer;

begin
  ...
  Anzahl := cList.Count - 1; 
  for i := Anzahl downto 0 do
  begin
    IntToStr(i));
  end;
  ...
end;

[himitsu]

Welche Delphi-Version?

Es gab mal den Bug, wo Int64 teilweise wie UInt64 behandelt wurde. (oder war's andersrum)

[SneakyBagels]

Zitat:

Bleibt der Fehler auch, wenn Du das mal so abänderst?

Ja. Denn Anzahl enthält dann ja cList.Count wo begonnen wird zu zählen.

Tokyo.

[Luckie]

Und was passiert, wenn du die Codeoptimierung deaktivierst?

[SneakyBagels]

Mit deaktivierter Codeoptimierung passiert das nicht.

[Luckie]

Aha. Dann sind wir doch schon mal einen Schritt weiter. Dann wird da etwas falsch optimiert. Nur fände ich das recht ungewöhnlich und davon höre ich jetzt zum ersten mal. Zeig doch noch mal deinen vollständigen original Code. Ich denke, da ist irgendwas "unsauber" in deinem Code, der den Optimierungsprozess stolpern lässt.

[SneakyBagels]

Das geht leider nicht denn dann müsste ich rund 1000 Zeilen hier schicken.

Wenn das wirklich die Code-Optimierung ist die da nicht mit klar kommt dann belasse ich es einfach bei

Delphi-Quellcode:

if i < 0 then Break;

[Luckie]

Eine Prozedur/Funktion 1.000 Zeilen? :shock:

[SneakyBagels]

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt und ich habe keine Lust aufzuräumen :P (irgendwann einmal aber nicht in naher Zukunft)

In der 32 Bit Version gibt es diesen Fehler nicht. Also gehe ich von einem Compiler-Problem aus.

[nahpets]

Wenn die Codeoptimierung ein Problem mit 'ner einfachen For-Schleifen beim DownTo hat, würd' ich aber nicht nach irgendeiner zusätzlichen Abfrage suchen, die das Problem umschifft, sondern auf die Codeoptimierung verzichten.

Woher willst Du denn wissen, ob das die einzige Stelle ist?

Oder suchst Du bei anderen Fehlern dann auch jeweils nach 'nem Workaround?

Als Ersatz könnte man dann eher eine Repeat-Until- oder eine While-Schleife nehmen, statt auf einen Wert abzufragen, der garnicht vorkommen darf.

'ne Quelltextdatei mit 1000 Zeilen als Anlage, dürfte aber nicht zuviel sein, da kann man durchaus mal drüberschauen und Hilfestellung geben.

[Uwe Raabe]

Zitat:

Zitat von SneakyBagels (Beitrag 1371193)

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt

Tut er nicht!

[SneakyBagels]

Zitat:

Zitat von Uwe Raabe (Beitrag 1371196)

Zitat:

Zitat von SneakyBagels (Beitrag 1371193)

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt

Tut er nicht!

Rechnen wir diesen Schluckauf mal raus, dann tut er es :thumb:

Ich konnte das Suchgebiet eingrenzen. Ich rufe an einer Stelle vorher eine Funktion auf welche 5 Parameter akzeptiert. Drei davon sind

Delphi-Quellcode:

TFile.GetCreationTime(s), TFile.GetLastAccessTime(s), TFile.GetLastWriteTime(s)

s beinhaltet einen Pfad zu einer Datei. Der Code wird nicht immer ausgeführt. Nur sehr sehr selten und hier in meinem Fall sogar gar nicht.
Wenn ich 1x TFile.... weglasse und durch Now ersetze, funktioniert meine Schleife auch korrekt.

Hat der Compiler hier Schluckauf?

[Luckie]

Zitat:

Zitat von SneakyBagels (Beitrag 1371193)

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt

Tut er ja eben nicht, wie du siehst. Und mir wäre da jetzt etwas mulmig. Wer weiß, was da noch im Argen liegt. :|

[SneakyBagels]

Zitat:

Wer weiß, was da noch im Argen liegt.

Meine Schuld kanns ja nicht sein denn wenn dem so wäre, dann würde ja auch der 32 Bit Modus alles verhnunzen.

Und noch eine Erkenntnis.
Wenn ich die Schleifenvariale j verwende statt i (wie es just oben über der for-Schleife passiert denn da ist noch eine andere), dann kommt der Fehler auch nicht.

[Luckie]

Aber bevor das hier wieder eskaliert. Wir meinen es nur gut. Wir wollen deinen Code nicht schlecht reden oder dich fertig machen. Sehe es als Ratschlag und konstruktive Kritik. Wenn du damit leben kannst, OK. Aber sei dir bewusst, dass da im Code eventuell eine Zeitbombe tickt.

Zitat:

Meine Schuld kanns ja nicht sein denn wenn dem so wäre, dann würde ja auch der 32 Bit Modus alles verhnunzen.

Öhm. Kleines Gedankenspiel. Nehmen wir an es gäbe keinen 32-Bit Compiler, dann könntest du diese Aussage nicht mehr treffen, da du keine Kenntnis hast, wie ein 32-Bit Compiler deinen Code übersetzen würde. Wahrscheinlich ist es einfach nur Glück, dass es unter 32- Bit so übersetzt wird, wie du es wünschst.

[SneakyBagels]

Nur wie kann es sein, dass mir eine Schleifenvariable i scheinbar verhext wird von einem Code der nie angesprungen wird?
Ich bin gerade noch einmal alles grob durchgegangen und es passiert nur unter 64 Bit.

[Luckie]

Ja. Hilft wohl nichts. Häng die Unit mal an. Oder zeig die Prozedur in der der Fehler auftritt. Was mir einfällt: Wie sieht es mit den (Interger)Datentypen aus?

[nahpets]

Gibt es zufällig eine globale Variabel gleichen Namens?

Mach bitte aus j nochmal i, lasse aber die deklaration von i weg.

Eigentlich wäre zu erwarten, dass der Compiler dann die fehlende Deklaration bemängelt.

Sollte dem nicht so sein, wäre das mal eine Überprüfung wert.

Naja, dass der 32 Bit-Compiler richtig arbeitet und der 64er falsch, kann Zufall sein, könnte in anderen Situationen auch andersherum sein.
Die Wahrscheinlichkeit, dass beide oder einer von ihnen absolut fehlerfrei arbeitet, dürfte gegen Null tendieren.

[SneakyBagels]

Zitat:

Naja, dass der 32 Bit-Compiler richtig arbeitet und der 64er falsch, kann Zufall sein, könnte in anderen Situationen auch andersherum sein.

Pass auf was sagst du dazu.

Folgender Code steht genau so an der Stelle ab wo i plötzlich bis zu -1 geht

Delphi-Quellcode:

             for i := cList.Count - 1 downto 0 do
              ShowMessage(IntToStr(i));
             ShowMessage('End1');

             for i := cList.Count - 1 downto 0 do
              ShowMessage(IntToStr(i));
             ShowMessage('End2');

Zwischen den beiden Schleifen steht bis auf die ShowMessage nichts.

Unter XE8 64 Bit absolut keine Probleme. Generell gibts da keine Probleme. Tokyo spinnt hier rum und macht mir die Zicken mit dem -1.

Zitat:

Oder zeig die Prozedur in der der Fehler auftritt

Hatte ich auf Seite 2

Zitat:

Zitat von SneakyBagels (Beitrag 1371197)

Zitat:

Zitat von Uwe Raabe (Beitrag 1371196)

Zitat:

Zitat von SneakyBagels (Beitrag 1371193)

Sagen wir mal so: ein großer Thread, er funktioniert absolut perfekt

Tut er nicht!

Rechnen wir diesen Schluckauf mal raus, dann tut er es :thumb:

Ich konnte das Suchgebiet eingrenzen. Ich rufe an einer Stelle vorher eine Funktion auf welche 5 Parameter akzeptiert. Drei davon sind

Delphi-Quellcode:

TFile.GetCreationTime(s), TFile.GetLastAccessTime(s), TFile.GetLastWriteTime(s)

s beinhaltet einen Pfad zu einer Datei. Der Code wird nicht immer ausgeführt. Nur sehr sehr selten und hier in meinem Fall sogar gar nicht.
Wenn ich 1x TFile.... weglasse und durch Now ersetze, funktioniert meine Schleife auch korrekt.

Hat der Compiler hier Schluckauf?

Ist jetzt aber ehrlich gesagt total unwichtig. Ich habe die Stelle gefunden die den Fehler auslöst und schuld dran sind die drei TFile.

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1371205)

Ich habe die Stelle gefunden die den Fehler auslöst und schuld dran sind die drei TFile.

Wenn es wirklich so ist, dann dürftest du ein Speicherproblem haben. Sprich irgendwo Speicher überschreiben oder ähnliches. Denn anders wäre das kaum zu erklären...

Ob der Compiler hier etwas falsch macht, lässt sich leicht klären, indem du den Assemblercode der Schleife postest. Dafür brauchst du nur an der Stelle einen Haltepunkt setzen und Strg + Alt + C drücken. Dann siehst du den Assemblercode und dazu jeweils den Pascal-Code. Den kannst du dann einfach von Anfang bis Ende der Schleife kopieren und posten.

[SneakyBagels]

Wie genau komme ich denn an den Assemblercode? Breakpont ja gut aber Assembercode? Falls du das hier meinst

Delphi-Quellcode:

cThreadC.pas.1270: ShowMessage(IntToStr(i));
0000000000C0D1F8 488B8560090000   mov rax,[rbp+$00000960]
0000000000C0D1FF 8B4020           mov eax,[rax+$20]
0000000000C0D202 89859C000000     mov [rbp+$0000009c],eax
0000000000C0D208 488D8DB8040000   lea rcx,[rbp+$000004b8]
0000000000C0D20F 8B959C000000     mov edx,[rbp+$0000009c]
0000000000C0D215 E8469A82FF       call IntToStr
0000000000C0D21A 488B8DB8040000   mov rcx,[rbp+$000004b8]
0000000000C0D221 E88A83A4FF       call ShowMessage
uThreadC.pas.2523: end;                                    // Das hier ist das end vom Execute-Block
0000000000C0D226 488B8560090000   mov rax,[rbp+$00000960]
0000000000C0D22D 488D4020         lea rax,[rax+$20]
0000000000C0D231 832801           sub dword ptr [rax],$01
uThreadC.pas.1269: for i := cList.Count - 1 downto 0 do
0000000000C0D234 8B859C000000     mov eax,[rbp+$0000009c]
0000000000C0D23A 85C0             test eax,eax
0000000000C0D23C 7DBA             jnl TThreadC.Execute + $1498
uThreadC.pas.1271: ShowMessage('END');
0000000000C0D23E 488D0D77660000   lea rcx,[rel $00006677]
0000000000C0D245 E86683A4FF       call ShowMessage

Wie gesagt. Nur diese eine einzige Zeile mit dem 3x TFile kommentieren und das Problem ist weg nur seltsam ist es schon. Bzw. 1x von den 3 TFile rausnehmen reicht auch schon.

Gerade früh noch schnell einen Test gemacht. Lasse ich TFile... komplett weg und füge stattdessen das hier ein

Delphi-Quellcode:

function FileTimeToDateTime(FileTime: TFileTime): TDateTime;
var
 ModifiedTime: TFileTime;
 SystemTime: TSystemTime;
begin
 Result := 0;
 if (FileTime.dwLowDateTime = 0) and (FileTime.dwHighDateTime = 0) then
  Exit;
 try
  FileTimeToLocalFileTime(FileTime, ModifiedTime);
  FileTimeToSystemTime(ModifiedTime, SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
 except
  // Prevent a black whole
 end;

GetFileAttributesEx(PChar(s), GetFileExInfoStandard, @fileDate);

FileTimeToDateTime(fileDate.ftCreationTime),
FileTimeToDateTime(fileDate.ftLastAccessTime),
FileTimeToDateTime(fileDate.ftLastWriteTime),

dann ist der Fehler auch weg. Es scheint also zu 100% (?) etwas mit dem TFile-Record zu tun zu haben.

[mensch72]

Delphi-Quellcode:

for i := cList.Count - 1 downto 0 do
    ShowMessage(IntToStr(i));
ShowMessage('End1');

for i := cList.Count - 1 downto 0 do
    ShowMessage(IntToStr(i));
ShowMessage('End2');

Fragen:
- Ist das in einer "globalen" Funktion, in einer Objectfunktion oder in einer lokalen Funktion?
- Wie und wo und als was ist "i" deglariert ? (global, in Klasse, lokal / Integer,Cardinal,Int64,...)
- Tokio mit oder ohne Hotfix1

[jaenicke]

Die Schleife fängt schon etwas früher an (die steht doppelt drin, einmal am Anfang der Schleife einmal am Ende), aber zumindest die Abbruchbedingung der Schleife sieht vollkommen korrekt aus.

Die Speicheradresse für die Variable sieht etwas komisch aus, aber ich kenne hauptsächlich 32 Bit Assembler, den Delphi generiert. Das kann also völlig normal sein.

Der angezeigte Assemblercode ist allerdings der, der kompiliert wurde, nicht der, der im Speicher liegt.

Das und die Tatsache, dass eine Änderung an anderer Stelle das Problem löst, spricht tatsächlich für ein Speicherproblem.

Du kannst einmal schauen ob FastMM etwas findet.

[SneakyBagels]

Antworten

1. diese beiden Schleifen stecken mitten im Execute-Block eines Threads
2. i ist lokal im Execute-Block deklariert, ein globales i gibt es nicht
3. Tokyo noch ohne Hotfix da mir die Zeit fehlt eine etwaige Fehlinstallation zu reparieren

Ohne TFile ist der Fehler weg. XE8 hat mit den 3 TFile's keine Probleme. Das 32 Bit-Kompilat auch nicht. Nur Tokyo mit 64 Bit meckert.

Zitat:

Das und die Tatsache, dass eine Änderung an anderer Stelle das Problem löst, spricht tatsächlich für ein Speicherproblem.

Liegt das dann an mir oder am Compiler/an Delphi? Denn wie gesagt gibt es unter XE8 keinerlei Probleme weder 32 och 64 Bit.
Mit Speicherproblem meinst du aber keine defekte Hardware?

[jaenicke]

Nein, ich meine überschriebenen Speicher z.B., aber das heißt nicht, dass das an deinem eigenen Quelltext liegen muss. Es kann natürlich auch ein Fehler in der neuen Delphiversion sein. Die Wahrscheinlichkeit ist zwar nicht besonders hoch, aber möglich ist alles.

Ich schaue mir die Implementierungen einmal an.

[SneakyBagels]

Ich habe gerade auch flott mal drüber geguckt. Es gibt zwar von XE8 zu Tokyo einige Änderungen (45 laut Anzeige) aber das meiste betrifft nur Linux.

[Zacherl]

Definitiv ein Buffer-Overflow an irgendeiner anderen Stelle, der das Problem letztendlich verursacht. Viel Spaß beim Suchen :stupid: Deine Operationen mit

Delphi-Quellcode:

TFile

sind hier auch nicht umbedingt der Auslöser - können natürlich aber.

Nur zur Sicherheit:
Als was hast du

Delphi-Quellcode:

fileDate

deklariert, welches du an die GetFileAttributesEx API übergibst?

[SneakyBagels]

Zitat:

Definitiv ein Buffer-Overflow an irgendeiner anderen Stelle, der das Problem letztendlich verursacht. Viel Spaß beim Suchen Deine Operationen mit TFile sind hier auch nicht umbedingt der Auslöser - können natürlich aber.

Nur hier wieder die Fragen...
1: warum ist der Fehler komplett weg sobald ich TFile 2x verwende statt 3x (oder halt gar nicht)
2: warum nur bei 64 Bit
3: und warum nicht bei XE8

fileDate ist als TWin32FileAttributeData deklariert.

Woran erkennt man einen BufferOverflow denn? Was muss man da falsch machen um den zu erzeugen.

[Zacherl]

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

Zitat:

Definitiv ein Buffer-Overflow an irgendeiner anderen Stelle, der das Problem letztendlich verursacht. Viel Spaß beim Suchen Deine Operationen mit TFile sind hier auch nicht umbedingt der Auslöser - können natürlich aber.

Nur hier wieder die Fragen...
1: warum ist der Fehler komplett weg sobald ich TFile 2x verwende statt 3x (oder halt gar nicht)
2: warum nur bei 64 Bit
3: und warum nicht bei XE8

Sobald IRGENDWO ein BufferOverflow stattfindet, ist der restliche Programmablauf komplett undeterministisch (zumindest erscheint es unserer beschränkten Wahrnehmung so). Das mit Logik erklären zu wollen, ist grundsätzlich zum Scheitern verurteilt.
1. Dadurch verschieben sich die Variablen auf dem Stack / der Stack wird kleiner / anderer Code wird generiert, wodurch dann letztendlich vielleicht eine andere Variable überschrieben wird und nicht dein Schleifen-Zähler oder

Delphi-Quellcode:

List.Count

. Kann man nur spekulieren.
2. Auch hier wird anderer Code generiert / bestimmte Datentypen (Pointer z.b.) sind auf einmal 8-Byte statt 4-Byte groß, wodurch sich die Position der lokalen Variablen auf dem Stack ebenfalls wieder verändert.
3. Kann man wieder nur spekulieren. Vermutlich wird der Code hier auf andere Weise generiert / optimiert, weshalb sich erneut die Position der Variablen auf dem Stack ändern könnte.

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

fileDate ist als TWin32FileAttributeData deklariert.

Gut, das scheint korrekt zu sein (sofern du den Typ aus der Winapi.Windows.pas verwendest).

Zitat:

Zitat von SneakyBagels (Beitrag 1371247)

Woran erkennt man einen BufferOverflow denn? Was muss man da falsch machen um den zu erzeugen.

BufferOverflows sind fiese Fehler, die man nur schwer erkennen kann. Oft treten sie bei Verwendung von Arrays (Schreibzugriffe nach dem letzten validen Index) oder bei der Verwendung von untypisierten Pointern (wie z.b. im Falle von GetFileAttributesEx) auf. Wäre z.b. das

Delphi-Quellcode:

TWin32FileAttributeData

angenommen mal 4-Byte zu klein und auf dem Stack liegt zufälligerweise eine lokale Integer-Variable direkt hinter dem Struct, dann würde die API fehlerhafterweise den Wert der dahinterliegenden Variable mit "Irgendwas" überschreiben.

[SneakyBagels]

Zitat:

Oft treten sie bei Verwendung von Arrays (Schreibzugriffe nach dem letzten validen Index)

Solche Fehler zu vermeiden da achte ich peinlichst genau drauf.

Nur stellt sich mir noch immer die Frage, warum XE8 das Problem nicht hat Tokyo ohne HF aber schon. Und warum nur 64 Bit. Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.
Wenn es tatsächlich ein BufferOverflow irgendwo wäre (falscher Index Array ...), dann müsste ich doch schon vorher wenigstens Zugriffsverletzungen oder ähnliche Fehler sehen.

Wie bereits erwähnt besteht der Fehler erst seit dem Umstieg auf Tokyo.

FastMM4 zeigt keinerlei Auffälligkeiten. Memory Leaks gibt es auch keine.

[Zacherl]

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Nur stellt sich mir noch immer die Frage, warum XE8 das Problem nicht hat Tokyo ohne HF aber schon. Und warum nur 64 Bit. Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.

Ich kann mich an dieser Stelle nur nochmal selbst zitieren:

Zitat:

Sobald IRGENDWO ein BufferOverflow stattfindet, ist der restliche Programmablauf komplett undeterministisch (zumindest erscheint es unserer beschränkten Wahrnehmung so). Das mit Logik erklären zu wollen, ist grundsätzlich zum Scheitern verurteilt.

XE8 und Tokyo haben unterschiedliche Compilerversionen und damit auch unterschiedliche Codegenerierung und Codeoptimierung. Ebenso unterscheidet sich die Codegenerierung zwischen 64 und 32 Bit (unter anderem in der von mir erwähnten Form der unterschiedlichen Größe bestimmter Datentypen).

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Dann müsste das 32er Kompilat ja auch Probleme haben wenn es ein Codefehler wäre.

Die Annahme ist leider falsch. Unter 32-Bit wird sehr wahrscheinlich einfach eine Speicherstelle überschrieben, die zu diesem Zeitpunkt schon irrelevant oder sogar komplett unbenutzt ist.

Zitat:

Zitat von SneakyBagels (Beitrag 1371252)

Wenn es tatsächlich ein BufferOverflow irgendwo wäre (falscher Index Array ...), dann müsste ich doch schon vorher wenigstens Zugriffsverletzungen oder ähnliche Fehler sehen.

Die Annahme ist ebenfalls falsch. Es kommt erst dann zu Fehlern, wenn dein Code die überschriebenen Speicherbereiche verwendet und an der dortigen Stelle bestimmte Daten erwartet, die dann natürlich nicht mehr stimmen. Das KANN eine Zugriffsverletzung sein (sofern z.b. nochmal eine Dereferenzierung stattfindet), kann aber auch genausogut andere Seiteneffekte haben. Kaputte Schleifenzähler sind hier sogar sehr häufig.

[SneakyBagels]

Zitat:

XE8 und Tokyo haben unterschiedliche Compilerversionen und damit auch unterschiedliche Codegenerierung und Codeoptimierung.

Jetzt bin ich hin und her gerissen und weiß nicht, ob ich jetzt einen BufferOverflow suchen soll oder nicht.
Ich bin mir aber 100% sicher, dass ich selber keine eingebaut habe.

[Zacherl]

Also es gibt auch Tools, um BufferOverflows zu erkennen. Leider habe ich damit nur Erfahrung bei Visual Studio und kann dir für Delphi hier nicht großartig weiterhelfen.