EIntOverflow bei LongWord, nicht aber bei Word

[Der schöne Günther]

Warum?

Delphi-Quellcode:

{$OVERFLOWCHECKS ON}

procedure acceptDouble(const input: Double);
begin
   //
end;

procedure p();
var
   a, b: Word;
   x, y: LongWord;
begin
   a := 1000;
   b := 10000;
   acceptDouble(a-b);

   x := 1000;
   y := 10000;
   acceptDouble(x-y); // << EIntOverflow
end;

[freimatz]

Ich vermute mal bei Word macht er implizit eine Erweiterung auf Int64. Bei LongWord geht das nicht.
Kam keine Warnung?

[himitsu]

Bedenke auch, dass erst gerechnet und dann das Ergebnis konvertiert wird.

Das WORD wird wohl einfach nach INTEGER für die Berechnung gecastet.
Größer als SizeOf(Pointer) werden aber keine automatischen Castes vorgenommen.

[Der schöne Günther]

Zitat:

Zitat von freimatz (Beitrag 1403213)

Kam keine Warnung?

Nö.

Zitat:

Zitat von himitsu (Beitrag 1403217)

Größer als SizeOf(Pointer) werden aber keine automatischen Castes vorgenommen.

Aber es ist doch

Delphi-Quellcode:

SizeOf(Pointer) = SizeOf(LongWord)

?


PS: Verhalten bei Win32 und Win64 identisch.

[himitsu]

Ja, aber er würde danach größer sein.
Ich weiß jetzt nicht wie es im 64 Bit ist,
aber in 32 Bit wird maximal bis auf Größe der CPU-Register vergrößert.

[Der schöne Günther]

Verstehe ich nicht.

Das

Delphi-Quellcode:

-9000

nicht im Bereich eines LongWord (0..4 Mrd.) liegt ist mir klar, aber was wird denn hier vergrößert? Bei Word (0..65535) scheint er ja keine Probleme zu haben. Weshalb sollte er hier überhaupt auf einen signed Typen vergrößern?


Und wo wäre so etwas überhaupt dokumentiert?

Und wie komme ich jetzt überhaupt aus der Sache raus? Statt

Delphi-Quellcode:

acceptDouble(x-y)

ein

Delphi-Quellcode:

acceptDouble( (x*1.0) - (y*1.0))

wird ja wohl kaum die richtige Lösung sein...

[himitsu]

Bei dem Word wird der Compiler das einfach schon vorher casten, weil er 32 Bit halt am Liebsten hat.

Delphi-Quellcode:

   acceptDouble(Double(Integer(a) - Integer(b)));

   acceptDouble(Double(x - y));

[Stevie]

Weil overflow checking nicht richtig bei Datentypen funktioniert, die kleiner als 32bit sind, da die Rechenoperationen auf den 32bit Registern ausgeführt werden.

Versuch doch mal das:

Delphi-Quellcode:

a := High(Word);
a := a + 1;

Disassembly für die 2. Zeile:

Delphi-Quellcode:

0041A834 0FB745FE         movzx eax,[ebp-$02]
0041A838 83C001           add eax,$01
0041A83B 7105             jno $0041a842
0041A83D E836ACFEFF       call @IntOver
0041A842 668945FE         mov [ebp-$02],ax

jno ist "Jump if not overflow" - und hier gabs nunmal keinen Overflow, denn eax ist 32bit breit. Wenn er in Variable zurückschreibt, spricht er es allerdings nur als 16-bit an (ax).

Schreibst du allerdings statt

Delphi-Quellcode:

a := a + 1;

Delphi-Quellcode:

Inc(a);

, dann gibts nen overflow. :wall:
Denn das wird zu

Delphi-Quellcode:

0041A85C 668345FE01       add word ptr [ebp-$02],$01
0041A861 7305             jnb $0041a868
0041A863 E810ACFEFF       call @IntOver

[Der schöne Günther]

Ich kann mit Assembler nichts anfangen, glaube das jetzt aber (Weißkittel-Syndrom).

Ist das irgendwo dokumentiert? Wie verhält sich das auf Win64? Wie verhält sich das, sollte ich (Gott bewahre!) etwas auf iOS oder Android kompilieren wollen? Ist das immer noch alles 32 Bit?

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1403230)

Ich kann mit Assembler nichts anfangen, glaube das jetzt aber (Weißkittel-Syndrom).

Ist das irgendwo dokumentiert? Wie verhält sich das auf Win64? Wie verhält sich das, sollte ich (Gott bewahre!) etwas auf iOS oder Android kompilieren wollen? Ist das immer noch alles 32 Bit?

Es verhält sich irgendwie, bis es jemand als Bug reported und dann ist dieses Verhalten as designed :mrgreen:

Aber mal ehrlich - keine Ahnung.