AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

Offene Frage von "himitsu"
Ein Thema von Der schöne Günther · begonnen am 19. Sep 2014 · letzter Beitrag vom 10. Feb 2022
Antwort Antwort
Seite 3 von 3     123
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#21

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 12:22
function Test(i: Integer): string; wird vom Compiler intern als 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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.114 Beiträge
 
Delphi 10 Seattle Enterprise
 
#22

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 12:22
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?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.247 Beiträge
 
Delphi 12 Athens
 
#23

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 13:10
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Delphi-Laie

Registriert seit: 25. Nov 2005
1.474 Beiträge
 
Delphi 10.1 Berlin Starter
 
#24

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 14:04
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.
  Mit Zitat antworten Zitat
Benutzerbild von smallie
smallie

Registriert seit: 8. Jan 2013
17 Beiträge
 
Delphi 10.3 Rio
 
#25

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 14:09
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.
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors."
  Mit Zitat antworten Zitat
Delphi-Laie

Registriert seit: 25. Nov 2005
1.474 Beiträge
 
Delphi 10.1 Berlin Starter
 
#26

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 14:15
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.

Geändert von Delphi-Laie (19. Sep 2014 um 14:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#27

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 14:43
@smallie


Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#28

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 14:59
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.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.114 Beiträge
 
Delphi 10 Seattle Enterprise
 
#29

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 7. Jun 2015, 14:56
Alle Jahre wieder:
Blogbeitrag: A silent danger
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.247 Beiträge
 
Delphi 12 Athens
 
#30

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 10. Feb 2022, 14:44
function Test(i: Integer): string; wird vom Compiler intern als 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, ...

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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:49 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz