View Full Version : Fehler ILERPG Runtime mit CONST-Parametern
Heute bin ich doch tatsächlich mal auf einen Fehler in der Runtime gestoßen:
Wenn ein Parameter mit "CONST" übergeben wird, wurde immer behaupted, dass eine Kopie des Wertes an die Funktion übergeben wird.
Der Compiler prüft dann, ob es eine Zuweisung zu diesem Feld gibt und lehnt die Umwandlung dann ab.
Hat man aber ein Feld in einer qualified DS und übergibt ein Feld daraus per CONST und die DS per Reference, ist das CONST-Feld nicht vor Überschreiben geschützt.
Der Compiler stell nämlich fest, dass Feld und Parameter identisch definiert sind und legt dann keine Kopie an.
dcl-ds MyDs;
F1 int(5);
end-ds;
dcl-pr MyFunc;
Func int(5) const;
RefDs likeds(MyDs);
end-pr;
callp MyFunc(MyDs.F1 : MyDs);
dcl-proc MyFunc;
dcl-pi *n;
Func int(5) const;
RefDs likeds(MyDs);
end-pi;
clear MyDs;
if Func = 1;
MyDs.F1 = 5;
endif;
end-proc;
Wird der Parameter als "VALUE" definiert funktionierts, da dann immer eine Kopie erstellt wird.
... CONST übergibt per (hoofentlich) read only Reference und müsste eigentlich hopefully const heißen.
VALUE ist da sicherer, fummelt aber auch im Aufrufer rum, was external UDF nicht abkönnen.
D*B
VALUE geht auch nur bei internen Aufrufen und Service-Programmen, ansonsten mag der Compiler das schon nicht. Dies liegt an der anderen Verarbeitung im MI (habe ich in V2 mal herausgefunden). VALUE wird nicht im Auto-Storage sondern im Stack abgelegt, was bei externen Aufrufen nicht geht, da MI das nicht unterstützt.
Mein Beispiel löscht den übergebenen Parameter MyDS.F1 in der Prozedur.
dschroeder
17-03-20, 09:23
Ich möchte mich auch mal kurz einmischen. Nach meinem Kenntnisstand ist const eine Übergabe per Referenz, also keine Kopie. Der Compiler verspricht nur, darauf aufzupassen, dass es keine Anweisungen gibt, die den Wert ändern.
Ich habe mich allerdings schon immer gefragt, wie bestimmte Konvertierungen funktionieren. Wenn ich einen Parameter als z.B. als varucs2 const deklariere, kann ich beim Aufruf problemlos einen normalen char-Wert übergeben. Irgendwie widerspricht das in meinen Augen dem Call by Reference. Der Wert, auf den der varucs2-Wert zeigt, ist ja nicht wirklich ein varucs2, sondern ein char. Aber es klappt.
Dass const grundsätzlich eine Übergabe per Referenz ist, habe ich aber bereits (leidvoll) erfahren müssen, als ich folgende seltsame Problematik in einem PGM gefunden habe:
Im PGM wurde eine Variable X global deklariert
X wurde an eine Procedure per Parameter übergeben und unter dem Namen Y const empfangen (Ich weiß, dass war unnötig, denn X war ja global)
Innerhalb der Procedure wurden keine Änderung an Y durchgeführt. Geht ja auch nicht, denn Y wurde ja const empfangen.
Im weiteren Verlauf wurde innerhalb der Procedure jedoch die globale Variable X verändert. Und damit war sofort auch Y verändert. Damit hatte man nicht gerechnet, da Y ja const war. Aber (ich denke wegen des call by reference) wurde sofort Y wertmäßig zu X
Aber vielleicht weiß ja jemand, wie die Konvertierung zwischen den Datentype klappt, auch wenn const ein "call by reference" ist.
Gruß,
Dieter
Aber vielleicht weiß ja jemand, wie die Konvertierung zwischen den Datentype klappt, auch wenn const ein "call by reference" ist.
Gruß,
Dieter
Wenn ein Parameter mit CONST definiert wurde, wird die Adresse des Original-Feldes an die aufgerufene Prozedur übergeben, sofern Datentyp und Länge mit der Parameter-Definition übereinstimmen.
Bei abweichender Länge bzw. compatiblem Datentypen, wird ein Hilfs-Feld im erwarteten Format mit der entsprechenden Länge generiert und mit den Parameter-Daten aktualisiert. Anschließend wird dann die Adresse des Hilfsfeldes an die aufgerufene Prozedur übergeben.
Da nie sicher ist, ob es sich bei dem übergebenen Pointer um die Adresse des Original-Feldes oder des generierten Hilfsfeldes handelt, dürfen die übergebenen Daten in der aufgerufenen Prozedur nicht geändert werden.
In Baldurs Fall wird 2x die Adresse des Original-Feldes (einmal als Parameter und einmal als Datenstruktur-Unterfeld) übergeben. Da die Datenstruktur via Reference übergeben wurde, ist das Unterfeld nicht vor Überschreibung geschützt. Damit kann das Datenstruktur-Unterfeld geändert werden. Da jedoch bei dem Parameter, der mit CONST übergeben wurde die gleiche Adresse übergeben wurde, kann der Wert trotzt CONST geändert werden.
Bei VALUE hingegen wird immer ein Duplikat des Feldes erzeugt und dieses an die Prozedur übergeben.
M.E. ist das kein Bug, sondern eine bescheidene Programmierung.
Falls in einem solchen Fall in Zukunft ein Compile-Fehler auftreten sollte, würde ich empfehlen einen RFE (Recall for Enhancement) bei der IBM zu eröffnen.
Birgitta
dschroeder
17-03-20, 09:57
Vielen Dank Birgitta und auch von mir noch herzlichen Glückwunsch zum IBM-Champion !
Das heißt, dass ein const nur bei komplett gleichem Datentyp ein "call by reference" ist und wenn es abweichend ist, dann ist es ein "call by value" ?
Dieter
Nicht ganz:
Bei call by VALUE wird nicht die Adresse sondern das ganze Feld an die rufende Prozedur übergeben.
Bei constant Reference wird immer eine Adresse weitergegeben, je nachdem die Adresse des Original-Feldes oder des Hilfs-Feldes
Birgitta
Nun habe ich (leider) erwartet, dass CONST eben grundsätzlich eine Kopie erstellt. Dann träte dieses Problem ja erst gar nicht auf.
Nun habe ich (leider) erwartet, dass CONST eben grundsätzlich eine Kopie erstellt. Dann träte dieses Problem ja erst gar nicht auf.
Dann wär's nicht besser als VALUES, bei dem immer eine Kopie erstellt wird.
dschroeder
17-03-20, 12:13
Nicht ganz:
Bei call by VALUE wird nicht die Adresse sondern das ganze Feld an die rufende Prozedur übergeben.
Bei constant Reference wird immer eine Adresse weitergegeben, je nachdem die Adresse des Original-Feldes oder des Hilfs-Feldes
Aber wenn die Adresse eines Hilfsfeldes übergeben wird, ist es doch ein call per Value, oder? Es muss doch erstmal eine Hilfskopie des Originalfeldes erstellt werden, denke ich.
Deshalb habe ich das jetzt alles so verstanden: bei VALUES wird immer eine Kopie erstellt, bei CONST nur manchmal.
Ist das korrekt?