CopyFileEx und Codeoptimierung XE5

[Sir Rufo]

Die Erklärung ist auch unter CopyFileEx und Windows Data Types zu finden.

pbCancel ist vom Typ ein LPBOOL , der wiederum ein Pointer auf ein BOOL ist und das ist vom Typ ein INT .

Ein BOOLEAN ist ein BYTE .

Ich habe aber auch erst jetzt nachgesehen

[Der schöne Günther]

Alter Schwede, den Fehler habe ich dann aber auch schon ein paar mal gemacht!

Bislang ist mir noch nichts um die Ohren geflogen...

[DeddyH]

Bei LPBOOL böte sich der generische Typ BOOL an (in Windows.pas als LongBool deklariert), dann sollte das doch automatisch passen, oder?

[Uwe Raabe]

Zitat von DeddyH:

Bei LPBOOL böte sich der generische Typ BOOL an (in Windows.pas als LongBool deklariert), dann sollte das doch automatisch passen, oder?

Genau dafür gibt es den ja auch.

[DeddyH]

Ja eben

[wurzelzwerg]

Das perverse war ja dass es bei mir ohne Codeoptimierung funktioniert hat.

[Uwe Raabe]

Zitat von wurzelzwerg:

Das perverse war ja dass es bei mir ohne Codeoptimierung funktioniert hat.

Das liegt wohl eher an den zufälligen Werten in den 3 höheren Bytes, die mit und ohne Optimierung halt andere Inhalte haben. War das jetzt sowas wie ein Mini-Heartbleed?

[wurzelzwerg]

Random Bug
Na gut, habs grad noch überlebt

[himitsu]

Ich finde es ja praktisch, daß inzwischen immer mehr dieser APIs entweder direkt mit einem VAR-Parameter deklariert wurden, oder dass es davon eine entsprechende überladene Version gibt.

Dort schlägt dann die Typprüfung des Compilers zu und der Fehler wird schnell entdeckt.

[uligerhardt]

Zitat von himitsu:

Ich finde es ja praktisch, daß inzwischen immer mehr dieser APIs entweder direkt mit einem VAR-Parameter deklariert wurden, oder dass es davon eine entsprechende überladene Version gibt.

Dort schlägt dann die Typprüfung des Compilers zu und der Fehler wird schnell entdeckt.

Wenn man in den Compileroptionen "Typisierter Adressoperator" einschaltet, hätte der Compiler hier vermutlich auch gemeckert. Ärgerlich, dass das defaultmäßig deaktiviert ist.