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
Mikkey

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 10: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.201 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 10: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 10:45 Uhr)
  Mit Zitat antworten Zitat
Mikkey

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 11:01
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.
  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, 11:49
Mein Weltbild gleicht nun einem Scherbenhaufen.
Armer Kerl

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

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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.688 Beiträge
 
Delphi 12 Athens
 
#6

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

  Alt 19. Sep 2014, 10:51
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Mikkey

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

AW: Warum keine Compilerwarnung bei offensichtlicher Bereichsüberschreitung

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

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

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
44.400 Beiträge
 
Delphi 12 Athens
 
#9

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.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Antwort Antwort


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 17:28 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz