Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

[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.