Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

[Der schöne Günther]

Ich dachte ja, ich wäre nun lange genug bei Delphi dabei, aber hiermit bin ich wieder auf die Nase gefallen:

Delphi-Quellcode:

program Project3;

{$APPTYPE CONSOLE}

{$R *.res}

uses
   System.SysUtils;
var
   myWord: Word;
   myInteger: Integer;
begin
   myInteger := myWord.MaxValue + 1;
   myWord := myInteger;
   WriteLn(myWord);
   WriteLn(myInteger);
   ReadLn;
end.

Ich stecke einen riesigen Integer in ein nur halb so großes Word. Niemanden kümmert es. Der Compiler (Win32) ist zufrieden. Warum?

Ich weiß dass ich Bereichs- und Überlaufprüfung anschalten und hoffen kann, dass es zur Laufzeit im Debugger auffällt. Aber warum gibt der Compiler mir keine Warnung? Bei impliziten Downcasts von String auf AnsiString tut er es ja auch...

[himitsu]

Der Compiler weiß doch nicht, ob da nicht zufällig später (zur Laufzeit) mal ein Wert drin ist, der da reinpassen könnte. :zwinker:

Delphi-Quellcode:

{$OVERFLOWCHECKS ON}

oder in den Projektoptionen aktivieren.

Der Delphi-Compiler merkt sich nicht den Inhalt von Variablen (aus Konstanten) und kann dann später auch nicht wissen ob es passt.
Drum kann der Compiler auch nicht Bescheid geben, wenn man vergißt ein Result zu initialisieren, welches vom Typ String, dyn. Array, Variant oder Interface ist. :wall:

Zitat:

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

Bei impliziten Downcasts von String auf AnsiString tut er es ja auch...

Wobei der auch meckert, wenn du einen AnsiString an einen UnicodeString übergibst, auch wenn das doch wohl eindeutig passen würde. :lol:

[Der schöne Günther]

Verstehe ich nicht: Ein Integer ist doppelt so groß. In 50% aller möglichen Wertebelegungen lässt sich kein Downcast durchführen.

Deshalb erwarte ich eigentlich wenigstens eine Warnung bei einem impliziten Downcast mit Werteverlust.

[himitsu]

Sehr viele deklarieren ihre Variablen einfach nur blind als Integer, tun aber dann aber nur kleine Werte da rein, welche auch in ein Byte/Bit passen würden.
Dann würde der Cast zu 100% fuktionieren. :stupid:

[p80286]

Zitat:

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

Verstehe ich nicht: Ein Integer ist doppelt so groß. In 50% aller möglichen Wertebelegungen lässt sich kein Downcast durchführen.

Deshalb erwarte ich eigentlich wenigstens eine Warnung bei einem impliziten Downcast mit Werteverlust.

Wenn Du mit einem 40tonner vorfährst um mir eine Kiste Bier in meinen Fiat500 zu stellen würde ich zwar an Deiner geistigen Gesundheit zweifeln aber gehen tut das:wink:

Nur weil die Kapazität des einen Typen größer ist, heißt das noch lange nicht, das der Wert nicht passt. Und es soll Programmierer geben, die genau mit diesen Effekten arbeiten.

Gruß
K-H

p.s.
wieso eigentlich Bereichsüberschreitung?
Ist doch kein Array,String oä.

[MEissing]

Einfache Antwort: Wenn Delphi (der Delphi-Compiler) alles testen würde, was eventuell schief gehen könnte, dann wären die Übersetzungszeiten länger.

[Win32.API]

Dieser Thread zeigt mir mal wieder auf, wieso ich nicht länger mit Delphi programmiere. Auch wenn ich die Sprache nach wie vor sehr mag.

Zitat:

Zitat von himitsu (Beitrag 1273116)

Sehr viele deklarieren ihre Variablen einfach nur blind als Integer, tun aber dann aber nur kleine Werte da rein, welche auch in ein Byte/Bit passen würden.
Dann würde der Cast zu 100% fuktionieren. :stupid:

Wenn eine Programmiersprache von Unwissenheit der Benutzer ausgeht, ist dies IMHO ein sehr schlechtes Zeichen.

Zitat:

Zitat von p80286 (Beitrag 1273118)

Nur weil die Kapazität des einen Typen größer ist, heißt das noch lange nicht, das der Wert nicht passt. Und es soll Programmierer geben, die genau mit diesen Effekten arbeiten.

Darum gibt es ja explizite Casts, wenn dies erforderlich ist. Wird der Cast implizit vom Compiler durchgeführt ist dies schlicht und einfach ein Grund für eine Warnung mit möglichem Datenverlust. Punkt.

Zitat:

Zitat von MEissing (Beitrag 1273120)

Einfache Antwort: Wenn Delphi (der Delphi-Compiler) alles testen würde, was eventuell schief gehen könnte, dann wären die Übersetzungszeiten länger.

LOL, das setzt dem Rest dieses Thread echt noch ein Sahnehäubchen auf.

[Zoot]

Zitat:

Zitat von Win32.API (Beitrag 1273121)

Dieser Thread zeigt mir mal wieder auf, wieso ich nicht länger mit Delphi programmiere.

:roll:

[Mikkey]

Zitat:

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

Verstehe ich nicht: Ein Integer ist doppelt so groß. In 50% aller möglichen Wertebelegungen lässt sich kein Downcast durchführen.

In 99,9969482421875% aller möglichen Wertebelegungen lässt sich kein Downcast durchführen (nämlich, wenn das High-Order-Word nicht Null ist).

Ich würde auch erwarten, dass zumindest ein Hinweis in der Art "possible data loss" kommt. Den habe ich auch in Delphi7 (und auch bei MS-Compilern) schon gesehen. Schließlich gehen hier nicht nur große Zahlen flöten, sondern auch ein evtl. vorhandenes Vorzeichen.

[Der schöne Günther]

Win32.API, meine Worte. :-/

Also ich hoffe bislang auch immer noch, dass ich nur einen dummen Schalter übersehe- In Java oder C# ist das mit Standardeinstellungen sogar ein beinharter Fehler der die Kompilierung abbricht!

[Uwe Raabe]

Zitat:

Zitat von Mikkey (Beitrag 1273127)

Ich würde auch erwarten, dass zumindest ein Hinweis in der Art "possible data loss" kommt. Den habe ich auch in Delphi7 (und auch bei MS-Compilern) schon gesehen.

Soweit ich weiß, bringt auch Delphi 7 hier keine Warnung. Das lässt sich aber sicher leicht nachprüfen.

[Mikkey]

Immerhin gibt es

Zitat:

W8071: Bei Konvertierung könnten signifikante Ziffern verloren gehen

Hier, beim Zuweisen von TStream.Size (__int64) auf einen DWord. Aber zu dieser C++ Warnung gibt es in der Liste der Delphi-Meldungen kein Pendant

[Der schöne Günther]

Richtig, das habe ich auch beim c++-Builder gesehen. Ist standardmäßig leider auch nicht an, aber in C++ habe ich dafür noch Verständnis ;-)

Aber man hat die Option. In Delphi sehe ich nichts. Ich bin die letzten 18 Monate wirklich immer davon ausgegangen, dass ich vor so etwas gewarnt werden würde.

Mein Weltbild gleicht nun einem Scherbenhaufen.

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1273112)

Drum kann der Compiler auch nicht Bescheid geben, wenn man vergißt ein Result zu initialisieren, welches vom Typ String, dyn. Array, Variant oder Interface ist. :wall:

Wieso nicht? C# kann das doch auch. Eine Variable ist genau dann nicht initialisiert, wenn -grob gesehen- das erste Anfassen der Variablen keine Zuweisung an diese Variable ist, also

Delphi-Quellcode:

if (variable) then...
CallMethod(variable); // Parameter ist kein var/out
someOtherVariable := variable;
variable := variable + 1;

Was vergessen? Bestimmt. Aber das Prinzip ist klar.

Zum Thema: So eine Warnung könnte der Compiler schon ausgeben und generell bei Konvertierungen zu warnen, wenn Daten verloren gehen könnten, dauert nun auch nicht länger, weil ja die konkrete Art der Konvertierung (Typ-A -> Typ-B) bekannt ist und man in einer einfachen Tabelle gucken könnte: "Meckern" / "Nicht meckern".

Ganz klar: Vergessen oder mit Absicht.

[Der schöne Günther]

Dass der Compiler auch nicht warnt, wenn man bestimmte Typen (z.B. Interface) zurückgibt und nie initialisiert hatten wir auch:
http://www.delphipraxis.net/175233-w...-zu-haben.html

Das ist der Grund warum ich mich fanatisch den Tag herbeibeschwöre an dem es endlich den "Nextgen"-Compiler für Windows gibt. Wenn die ganzen Altlasten weg sind kann Embarcadero hoffentlich endlich ein paar Compilerschalter mehr einbauen...

[p80286]

Zitat:

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

Mein Weltbild gleicht nun einem Scherbenhaufen.

Armer Kerl:duck:

Aber im Ernst, der weiter oben angesprochene cast sollte explizit erfolgen, worüber sich dann nur die AltenSäcke aufregen würden. Aber die Zeiten ändern sich halt.

Gruß
K-H

Zitat:

Zitat von Dejan Vu (Beitrag 1273146)

Zum Thema: So eine Warnung könnte der Compiler schon ausgeben und generell bei Konvertierungen zu warnen, wenn Daten verloren gehen könnten,

Ist das Vorzeichen auch schon ein Datum?
Da es durchaus Programierer gibt, die nicht wissen was sie tun (copy&paste) würde ich sagen: Ja

[Dejan Vu]

Dann werden doch nur alte Ärgernisse durch neue ersetzt. Obwohl. Abwechslung muss sein.

[himitsu]

Zitat:

Zitat von Dejan Vu (Beitrag 1273146)

Wieso nicht? C# kann das doch auch. Eine Variable ist genau dann nicht initialisiert, wenn -grob gesehen- das erste Anfassen der Variablen keine Zuweisung an diese Variable ist, also

Delphi-Quellcode:

if (variable) then...
CallMethod(variable); // Parameter ist kein var/out
someOtherVariable := variable;
variable := variable + 1;

Was vergessen? Bestimmt. Aber das Prinzip ist klar.

Nja, bestimmte Typen im Delphi werden automatisch verwaltet und da scheitert dann diese Prüfung, weil sie ja "im Prinzip" initialisiert sind.
Mit einem kleinen Problem, welcher aber erst auffällt, wenn man die Interna kennt. (drum wird auch bei einem Integer gewarnt, aber nicht bei einem String)

Delphi-Quellcode:

function Test1: Integer;
var
  i: Integer;
begin
  if i = 0 then ;
end;

function Test2: string;
var
  S: string;
begin
  if S = '' then ;
end;

[DCC Warnung] ...: W1036 Variable 'i' ist möglicherweise nicht initialisiert worden
[DCC Warnung] ...: W1035 Rückgabewert der Funktion 'Test1' könnte undefiniert sein
Aber bei den beiden Strings gibt es keine Warnung.

Wie gesagt, Strings (mit Ausnahme des ShortString) und andere Typen werden automatisch initialisiert, da sonst die automatische Speicherverwaltung nicht funktionieren würde.

Delphi-Quellcode:

function Test(i: Integer): string;

wird vom Compiler intern als

Delphi-Quellcode:

procedure Test(i: Integer; var Result: string);

umgesetzt.
Hier übernimmt der Aufrufer die Initialisierung, was oftmals nicht auffällt, aber ruf mal diese Funktion in einer Schleife auf. :stupid:

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1273151)

Dann werden doch nur alte Ärgernisse durch neue ersetzt.

Was meinst Du damit? zu int16-Zeiten hab ich den Integer nur genutzt wenn wirklich die Gefahr bestand, daß der Wert unter 0 sank. Inzwischen hab ich mich an int32 und word16 gewöhnt und laß die Finger von impliziten casts wann immer es geht. Das etwas geht heißt ja noch längst nicht, das es gut ist. Und wenn Delphi/Pascal sich auf die Fahnen geschrieben hat Typsicher zu sein ist zumindestens eine Warnung nicht schlecht. Irgendwo gibt's die auch, aber ich weiß jetzt nicht mehr den konkreten Wortlaut.

Gruß
K-H

[Mikkey]

Zitat:

Zitat von Uwe Raabe (Beitrag 1273135)

Soweit ich weiß, bringt auch Delphi 7 hier keine Warnung. Das lässt sich aber sicher leicht nachprüfen.

Da hast Du recht (ausprobiert), aber ich hätte schwören können...

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1273154)

Delphi-Quellcode:

function Test(i: Integer): string;

wird vom Compiler intern als

Delphi-Quellcode:

procedure Test(i: Integer; var Result: string);

umgesetzt.

Jetzt liegt meine Welt in Scherben. war da nicht mal was mit Rückgabe in AX und Mehr Register verfügbar??

Gruß
K-H

[Der schöne Günther]

Aber wir sind uns schon mal einig dass wir selbst im Jahr 2014 nicht einen Compilerschalter übersehen sondern es überhaupt nichts gibt?

Wir haben einen Konstanten als Variablen zu benutzen oder "Pentium 1-sicheres FDIV", warum nicht sowas?

[himitsu]

Jupp, gibt es nicht.

Du kannst dir aber einen RecordHelper schreiben und für die ungewollten Typen einen Class Operator implementieren, welcher als deprecated markiert wird. :stupid:

[Delphi-Laie]

Zitat:

Zitat von MEissing (Beitrag 1273120)

Einfache Antwort: Wenn Delphi (der Delphi-Compiler) alles testen würde, was eventuell schief gehen könnte, dann wären die Übersetzungszeiten länger.

Sicher. Und das schnelle Übersetzen ist unzweifelhaft eine der Stärken Delphis.

Jedoch ist die Anzahl der vordefinierten Typen wahrlich überschaubar. Dann erstellt man noch eine Rangliste ihrer Größen, aus der abgeleitet werden kann, welcher Wert in welchen anderen hunderprozentig hineinpaßt und es umgekehrt eben nicht gilt (oder die Typen sind sogar in beiden Richtungen vollkompatibel - wären die dann nicht sogar identisch?), und schon sind die Warnungen fertig. Evtl. wäre auch eine bidirektionale Adjazenzmatrix der Typen mit Kompatibilitätsgrad denkbar.

Das alles sollte im Zeitalter der GHz, GByte und Mehrkernprozessoren nicht nur machbar, sondern auch ratsam sein.

[smallie]

Zitat:

Zitat von p80286 (Beitrag 1273156)

Und wenn Delphi/Pascal sich auf die Fahnen geschrieben hat Typsicher zu sein ist zumindestens eine Warnung nicht schlecht. Irgendwo gibt's die auch, aber ich weiß jetzt nicht mehr den konkreten Wortlaut.

Du meinst dies?

Zitat:

W1023: Comparing signed and unsigned types - widened both operands
W1024: Combining signed and unsigned types - widened both operands

Delphi-Quellcode:

  var
    s : shortint;
    b : byte;

begin
  s := -128;
  b := 130;

  assert(b < s);
end.

Delphi-Quellcode:

{$APPTYPE CONSOLE}
program Produce;
  var
    i : Integer;
    c : Cardinal;

begin
  i := -128;
  c := 130;
  WriteLn(i + c);
end.

[Delphi-Laie]

Oder, um es noch einmal ganz plakativ und salopp zusammenzufassen:

Typenunverträglichkeit -> Compilerfehlermeldung und Compilierungsabbruch (so ist es seit Urzeiten).
Typenteilkompatibilität -> Compilerwarnung! Und zwar eine generelle, sowohl beim Vergleich als auch bei Wertzuweisungen.

[p80286]

@smallie
:thumb:

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1273154)

Nja, bestimmte Typen im Delphi werden automatisch verwaltet und da scheitert dann diese Prüfung, weil sie ja "im Prinzip" initialisiert sind.

Es gibt einen Unterschied zwischen
"Könnte Probleme geben, weil die Variable nicht initialisiert ist"
"Könnte Probleme geben, obwohl ich als Compiler dir die Variable auf 0 initialisiert habe, wobei es vielleicht auch nicht das ist, was Du wolltest"
"Sag mal, bist Du nur zu faul oder willst Du dich echt drauf verlassen, das ich dir die Variable heute mal zufällig auf 0 initialisiert habe, obwohl ich das nicht müsste, denn es steht nicht in meinem Vertrag"

Oder einfacher: Eine Variable nicht zu initialisieren ist einfach schlechter Programmierstil. Und da sollte ein Compiler, wenn er denn schon drüber stolpern kann, auch drüber stolpern. Das neuerdings vielleicht irgendwelche Strings initialisiert werden, mag ja ganz hübsch sein, aber das wird doch nur gemacht, damit der Compiler nicht
wegen CPU-Schutzverletzung angeklagt wird.

[Der schöne Günther]

Alle Jahre wieder:
Blogbeitrag: A silent danger

[himitsu]

Zitat:

Zitat von p80286 (Beitrag 1273158)

Zitat:

Zitat von himitsu (Beitrag 1273154)

Delphi-Quellcode:

function Test(i: Integer): string;

wird vom Compiler intern als

Delphi-Quellcode:

procedure Test(i: Integer; var Result: string);

umgesetzt.

Jetzt liegt meine Welt in Scherben. war da nicht mal was mit Rückgabe in AX und Mehr Register verfügbar??

Gruß
K-H

Weil ich's grad nochmal sehe.

Ja, die Rückgabe ist in Delphi in EAX bzw. RAX, wenn der Typ kleiner/gleich einem Register ist, also maximal Integer SizeOf(Pointer).
Aber gemangte Typen, also jene mit einer zwangsweisen Speicherverwalung/Initialisierung/Finalisierung, betrifft es nicht.
Die werden vom Ausrufer verwaltet und daher kommt dort das Result als impliziter VAR-Parameter hinten dran.
(genauso, wie bei Methoden und nicht-statischen Klassenmethoden vorne ein implizites Self reingeschmuggelt wird)

String, dynamisches Array, Interface, Variant, ...

Zitat:

Zitat von Delphi-Laie (Beitrag 1273179)

Jedoch ist die Anzahl der vordefinierten Typen wahrlich überschaubar. Dann erstellt man noch eine Rangliste ihrer Größen, aus der abgeleitet werden kann, welcher Wert in welchen anderen hunderprozentig hineinpaßt und es umgekehrt eben nicht gilt (oder die Typen sind sogar in beiden Richtungen vollkompatibel - wären die dann nicht sogar identisch?), und schon sind die Warnungen fertig. Evtl. wäre auch eine bidirektionale Adjazenzmatrix der Typen mit Kompatibilitätsgrad denkbar.

Es gibt nur die vordefinierten Typen.
Da zieht man einfach das eine Bit des Vorzeichens ab und wenn die restliechen Bits im Ziel weniger sind, dann passt es nicht. Sowie auch wenn die Quelle ein Vorzeichen hat und das Ziel nicht.
Zusammengefast/verkürzt sind das immer nur zwei einfache Prüfungen : signed ja/nein ist unterschiedlich und die geasamten Bits/Bytes sind im Ziel weniger.

Selbstgebaute Typen via Records/Objekten/Interfaces müssen sowas selber intern prüfen und nach außen bestehen sie ja wiederum nur aus den vordefinierten Typen.