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
Thema durchsuchen
Ansicht
Themen-Optionen

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 1 von 3  1 23      
Der schöne Günther

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

Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 10:23
Delphi-Version: XE5
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...
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

{$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.



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

Geändert von himitsu (19. Sep 2014 um 10:43 Uhr)
  Mit Zitat antworten Zitat
Der schöne Günther

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 10:56
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

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ä.
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector

Geändert von p80286 (19. Sep 2014 um 10:58 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von MEissing
MEissing

Registriert seit: 19. Jan 2005
Ort: Egelsbach
1.384 Beiträge
 
Delphi 12 Athens
 
#6

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 11:01
Einfache Antwort: Wenn Delphi (der Delphi-Compiler) alles testen würde, was eventuell schief gehen könnte, dann wären die Übersetzungszeiten länger.
Matthias Eißing
cu://Matthias.Eißing.de [Embarcadero]
Kein Support per PN
  Mit Zitat antworten Zitat
Win32.API

Registriert seit: 23. Mai 2005
312 Beiträge
 
#7

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 11:06
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.

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.
Wenn eine Programmiersprache von Unwissenheit der Benutzer ausgeht, ist dies IMHO ein sehr schlechtes Zeichen.


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.

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.
  Mit Zitat antworten Zitat
Zoot

Registriert seit: 30. Jan 2006
Ort: Hessen
113 Beiträge
 
Delphi 11 Alexandria
 
#8

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 11:17
Dieser Thread zeigt mir mal wieder auf, wieso ich nicht länger mit Delphi programmiere.

  Mit Zitat antworten Zitat
Mikkey

Registriert seit: 5. Aug 2013
265 Beiträge
 
#9

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 11:40
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!

Geändert von Der schöne Günther (19. Sep 2014 um 11:45 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23      


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 08:37 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