UInt64 Zuweisung an Integer, keine Warnung, Waum?

[KodeZwerg]

Hallo, warum gibt mir mein Delphi Rio keinen Hinweis bzw. keine Warnung wenn ich

Delphi-Quellcode:

Integer := UInt64

mache?
(im quelltext natürlich nicht so formuliert, nur inhaltlich um es nachzuvollziehen)

[Der schöne Günther]

Das Thema haben wir immer wieder
z.B. hier:
https://www.delphipraxis.net/181938-...chreitung.html

Dabei sind auch ganz interessante Meinungen wie

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.

[Stevie]

Zitat:

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

Dabei sind auch ganz interessante Meinungen wie

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.

interessant war nicht ganz das Adjektiv, was mir dazu als erstes eingefallen ist :roll:

Doof auch, wenn sich wegen solcher mangelnder Checks Defekte in RTL Code einschleichen, wa?

[KodeZwerg]

also ich habe den kommentar und den thread gelesen.

ich hätte gerne eine option die von mir aus langsamer kompiliert aber mich beschützt vor fehlschlägen ohne zu wissen an welcher stelle es klemmt.
wurde ja irgendwie dort alles bereits rumklabüsert.

Danke für die rasche Antwort!

[Stevie]

Der Kommentar ist übrigens extra lächerlich, da der Compiler sehr wohl um die Typenwandlung weiß, da er dort nämlich bei eingeschalteter Bereichsprüfung den Code für einen potenziellen ERangeError generiert. (viele Grüße von der Ariane 5 an dieser Stelle :lol: )

Tools wie Pascal Analyzer generieren bei solchen Zuweisungen schon lange eine Warnung.

[himitsu]

Und das ist eine Prüfung, die nun wirklich praktisch keine Zeit benötigt.
Ich denke mal die paar Millisekunden hierfür, fallen bei den anderen Langsamkeiten überhaupt nicht auf.

Dazu mal auch das Kompilieren mit RangeChecks nicht wirklich merklich langsamer wird.

[freimatz]

Dafür fallen die etlichen Stunden Fehlersuche diese Woche mit vier beteiligten Personen auf :evil:
ok, dass auch der Rangecheck aus war, war unser Fehler.

[dummzeuch]

Zitat:

Zitat von freimatz (Beitrag 1501985)

Dafür fallen die etlichen Stunden Fehlersuche diese Woche mit vier beteiligten Personen auf :evil:
ok, dass auch der Rangecheck aus war, war unser Fehler.

Willkommen im Club. Ganz toll ist es, wenn man aus Versehen im Debug-Mode RangeChecks nicht eingeschaltet hatte. Oder wenn es Units gibt, die damit nicht funktionieren, es aber nicht explizit ausschalten (MessageDigest_5 aus source\soap\wdslimporter lässt schön grüßen)

[Stevie]

Ok, offensichtlich habe ich durch ihre Abwesenheit in den Projektoptionen bedingt (ist bereits lange reportet) vergessen, dass es seit 10.2 folgende neue Warnungen gibt:

IMPLICIT_INTEGER_CAST_LOSS
IMPLICIT_CONVERSION_LOSS
COMBINING_SIGNED_UNSIGNED64

Wie gesagt kann man die derzeit leider nur über die $WARN Direktive im Code oder per dcc Kommandozeile steuern

[dummzeuch]

Zitat:

Zitat von Stevie (Beitrag 1502051)

Ok, offensichtlich habe ich durch ihre Abwesenheit in den Projektoptionen bedingt (ist bereits lange reportet) vergessen, dass es seit 10.2 folgende neue Warnungen gibt:

IMPLICIT_INTEGER_CAST_LOSS
IMPLICIT_CONVERSION_LOSS
COMBINING_SIGNED_UNSIGNED64

Wie gesagt kann man die derzeit leider nur über die $WARN Direktive im Code oder per dcc Kommandozeile steuern

Sind die nicht alle standardmäßig sowieso eingeschaltet?

[Redeemer]

1073 dürfte an sein, die anderen beiden nicht.

[Der schöne Günther]

Nein, keines der drei scheint standardmäßig aktiv.

Vielen Dank, das macht mein Leben fortan deutlich einfacher

Delphi-Quellcode:

program Project1;

{$WARN IMPLICIT_INTEGER_CAST_LOSS ON}
{$WARN IMPLICIT_CONVERSION_LOSS ON}
{$WARN COMBINING_SIGNED_UNSIGNED64 ON}

uses System.SysUtils;

var
   someByte: Byte;
   someShort: ShortInt;
   someInt: Integer;
   someUInt64: UInt64;
begin
   // W1071 Implicit integer cast with potential data loss from 'Byte' to 'ShortInt'
   someByte := ShortInt.MaxValue + 1;
   someShort := someByte;

   // W1072 Implicit conversion may lose significant digits from 'UInt64' to 'Integer'
   someUInt64 := UInt64.MaxValue;
   someInt := someUInt64;

   // W1073 Combining signed type and unsigned 64-bit type - treated as an unsigned type
   someUInt64 := someInt + someUInt64;
end.

[KodeZwerg]

Zitat:

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

Delphi-Quellcode:

{$WARN IMPLICIT_INTEGER_CAST_LOSS ON}
{$WARN IMPLICIT_CONVERSION_LOSS ON}
{$WARN COMBINING_SIGNED_UNSIGNED64 ON}

Dankeschön dafür!

Zitat:

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

das macht mein Leben fortan deutlich einfacher

Unbedingt :-D

[Der schöne Günther]

Gibt es, bei der Gelegenheit, vielleicht auch noch eine Compiler-Direktive die eine Warnung für nicht initialisierte Rückgabewerte aktiviert?

Also z.B. so etwas hier?

Delphi-Quellcode:

program Project1;

type
   TMyRecord = record
      a, b: Byte;
   end;

function returnRecord(): TMyRecord;
begin
   // do nothing
end;

var
   myRecord: TMyRecord;
begin
   myRecord := returnRecord();
   WriteLn(myRecord.a, ' ', myRecord.b);
   Readln;
end.

Ich würde ja selbst versuchen im DocWiki zu wühlen, aber das liefert mal wieder nur Server Error 500.

[himitsu]

Ja, bei kleinen Records funktioniert es garnicht.

Mit Integer, Byte, Char oder Pointer, als Result, da geht es.



Auch für gemangte Typen (ala String, Interface, Variant) und Results größer als Pointer, da ist das Result initialisiert, aus Sicht dieser Methode ... das sieht du nur nicht.

Denn intern wird es dort als

Delphi-Quellcode:

function returnRecord(var Result: TMyRecord);

kompiliert.

[Der schöne Günther]

Ja, an die Geschichte kann ich mich irgendwie erinnern.

Ist im Endeffekt aber doch wurscht zu was das kompiliert wird und was durch welche CPU-Register wandert - Fehlermeldungen und Warnungen zu offensichtlich falschem Code sind doch echt nicht zu viel verlangt.

[himitsu]

Gab es schon, als Idee.

Im Prinzip muß der Compiler bloß ein "Vergessen" bekommen ... zu Beginn der Methode wird für diese Variable gesagt "du bist nicht initialisiert".


Die führen ja irgendwo eine Liste, welche Variable was für einen Zustand hat und da müssten sie "blos" den Zustand umschreiben und fertig.
Aber ist wohl doch nicht so leicht, so dass es wohl nochmal 20 Jahre dauern wird.

[venice2]

Zitat:

Aber ist wohl doch nicht so leicht, so dass es wohl nochmal 20 Jahre dauern wird.

Es ist nun mal so wie es ist. Leider!

Wenn man offensichtliche Fehler findet werden diese von der Gemeinde hier schön geredet bis einem das letztendlich egal ist.
Aufzugeben ist daher die beste Lösung und solche oder ähnliche Probleme irgendwie selbst zu beheben wenn es auf die ein oder andere weise möglich ist.
Es bringt nichts sich darüber auszulassen oder aufzuregen. Bleib Ruhig :-D

[freimatz]

Bei der Sache mit "nicht initialisierte Rückgabewerte" ist es kein Fehler. Sie sind ja initialisiert und haben nicht einen zufälligen Inhalt.

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1502371)

Bei der Sache mit "nicht initialisierte Rückgabewerte" ist es kein Fehler. Sie sind ja initialisiert und haben nicht einen zufälligen Inhalt.

Das ist aus Sicht des Compilers sicher richtig. Für den Entwickler ist das aber nicht direkt ersichtlich. Andererseits, wer programmiert sollte schon wissen was er tut.

[himitsu]

Joar, aber manchmal wäre es schon nett, wenn potentielle Fehler wegen nichtinitialisierter Results kämen.

Delphi-Quellcode:

function Test(S: string): string;
begin
  //Result := '';  // nicht initialisert
  for var C in S do
    Result := Result + C;  // aka Result := S;
end;

procedure TForm16.FormCreate(Sender: TObject);
var
  S: string;
begin
  for var i := 1 to 5 do
    S := Test('Abc');
  ShowMessage(S);
end;

bzw.

Delphi-Quellcode:

procedure TForm16.FormCreate(Sender: TObject);
var
  S: string;
begin
  S := Test('Abc');
  S := Test('Abc');
  S := Test('Abc');
  ShowMessage(S);
end;

oder

Delphi-Quellcode:

procedure TForm16.FormCreate(Sender: TObject);
var
  S: string;
begin
  S := Test('Abc');
  ShowMessage(S);

  S := Test('Abc');
  ShowMessage(S);

  S := Test('Abc');
  ShowMessage(S);
end;

Tja, was würde man nun im Ausgang erwarten?

-> Einmal das, was Test macht, nichtwar?

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1502396)

Joar, aber manchmal wäre es schon nett, wenn potentielle Fehler wegen nichtinitialisierter Results kämen.

Genau genommen wegen nicht explizit initialisierter Results. Weil initialisiert sind sie ja, nur hatl nicht so wie man es erwartet.
Für mich ist es noch ein grosser Unterschied ob etwas initialisiert wie ich es nicht denke aber immer gleich ist - oder ob die Wert gar nicht initialisiert sind und sie also zufällig sind und z.B. davon abhängen was gerade auf dem Stack so rumliegt.
Das sind dann so Fehler die erst nach Monaten oder Jahren erscheinen weil irgend jemand woanders im Code etwas geändert hat oder man von 32 auf 64-Bit wechselt.
Die Fehler wegen vermeintlich nicht initialisierter Results merkt man dann entweder sofort oder auch nie. :-D