Hallo,
Zitat Zitat von Karl23

Können Sie sich in etwa den Aufwand vorstellen den alleine der CL-Scherz verursacht hat ?
Das war nicht meine Software, aber das ändert nichts.
Aber ich frage mal anders rum: Ist Ihnen irgendeine andere Spache bekannt, in der Sie einen 1024 stelligen String declarieren, diesen explizit leeren und im Ergebnis dann keine leeren String, sondern einen zugemüllten String vorfinden ?

Karl
dieser Effekt ist weder CL, noch überhaupt Sprachbezogen. Hier kommen mehrere Dinge zusammen:
- der gesamte Call Mechanismus von OS/400 basiert auf Call by Reference, sprich es werden Pointer auf Speicher übergeben - Parameter sind also immer im aufrufenden Kontext mit Speicher hinterlegt.
- ein OS/400 Pointer ist immer untypisiert, er weiß also nicht auf was er zeigt.
- Der OS/400 Command Call legt für Literale, die als Parameter übergeben werden Variablen an und übergibt deren Adresse als Pointer an das aufgerufene Programm; numerisch 15 5, alfa mit 32 Byte und nur dann länger, wenn das erkennbar und erforderlich ist, deshalb der Effekt beim verlängern und anfügen eines beliebigen Zeichens.

In der klassischen Denke waren eigene Commands als die Objekte gedacht, mit denen man Parameter Schnittstellen beschreiben kann. In der ILE Denke hat man hierfür Prototypen vorgesehen und verlagert dann die Prüfungen in die Compile Time und zusätzlich bekommt man die Möglichkeit mit der Angabe von VALUE dne stabileren Call by Value - sprich die Übergabe von Werten statt Adressen zu verwenden. Im engeren Sinne wird diese Art der Übergabe allerdings nur simuliert.
Mehr als am Rande sei bemerkt, dass die "zusätzlichen" Bytes am Schluss k e i n Garbage sind, sondern Speicher im aufrufenden Programm, sprich man kann Variablen überklopfen, die nicht übergeben wurden und früher konnte man sogar im Codesegment rummalen, und Programme, die im Call Stack weit tiefer lagen, abschießen; mittlerweile wird das leidlich überwacht.
Hier sollte sich defensives Vorgehen schon lange rumgesprochen haben und hat Probleme immer vermieden:

- Konstanten oder Variablen statt Literale verwenden (gilt übrigens auch für eval)
- automatisch angelegte Variablen generell vermeiden (gilt besonders für eval), das vermeidet auch Rundungsprobleme
- auf genaueste Übereinstimmung der Deklarationen von Schnittstellen Variablen achten.

Was den Vergleich von RPG und CL mit anderen Sprachen angeht: beide sind unverantwortlich lax und prüfen viel zu wenig, dafür unsinniges Zeug (siehe Pre-Compiler), da ist Java ungleich penibler und kooperativer zugleich - nur hier ist die Lage (mit Ile) eher besser als schlechter geworden.

mfg

Dieter Bender