XProfan

- Seite 2 -

Was hat ein NullByte mit der Redimensionierung zu tun?

Ein Print String$(B#,0) ist absolut nicht aussagekräftig da es hier bis zu einem NullByte liesst.

Wenn man in einem Bereich ein Null-Byte benötigt, weil eine Funktion wie string$ bis dort hin liesst, dann sollte man das NULL-Byte setzen.

Oder kappier ich nur etwas nicht?

Jörg
Sellmeyer

Wenn Profan einen Bereich dimensioniert, liest String$(...) den immer bis zu korrekt eingestellten Größe des Bereichs aus. Das macht es aber nicht mehr, wenn der Bereich neu dimensioniert wurde. Das hat nix damit zu tun, ob ich ein NullByte benötige, da das Abschlußbyte ja sonst auch von Profan gesetzt wird.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Jörg Sellmeyer

Wenn Profan einen Bereich dimensioniert, liest String$(...) den immer bis zu korrekt eingestellten Größe des Bereichs aus.

Wird nicht hauptsächlich bis zu einem Byte 0 gelesen?

RGH

String$ liest bis zum ersten Byte(0), Char$ die angegebene Anzahl Zeichen.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Jörg
Sellmeyer

Irgendwie drehen wir uns jetzt im Kreis, oder? Natürlich wird bis zum ersten NullByte gelesen. Wenn dimensioniert wird, wird diese Byte aber automatisch an die letzte Stelle gesetzt. Warum sollte Dim das bei der zweiten Anwendung anders machen. außerdem hat String$(...) so Zugriff auf Speicher, der schon nicht mehr zum Programm gehört. Das sollte meiner Meinung nicht sein. Nach dem zweiten Dim ist die Funktion String$ praktisch nutzlos.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Frank
Abbing

Jörg hat es genauso gesagt wie es ist. Das zweite String$ liest aus unerlaubtem Speicher. Die Redimensionierung ist in dieser Form fehlerhaft.

Es geht also nur darum, bei einer Vergrößerung des Speicherbereiches, den angehangenen Teil mit Null zu füllen?

Jörg
Sellmeyer

Nein!!! Es geht darum, bei einer Verkleinerung ein Nullbyte einzufügen:
Ein Bereich wird deklariert:
Kompilieren Markieren Separieren

Declare Bereich#

Dann wird er dimensioniert:
Kompilieren Markieren Separieren

Dim Bereich#,10

Dann sieht Bereich nach meinem Verständnis so aus:

0|0|0|0|0|0|0|0|0|z

Wobei 0 auch beliebige Daten sein können, die gerade an der Stelle im Speicher stehen. Es ist ja nicht mit Clear Bereich gelöscht.
Jetzt schreibe ich was rein:
Kompilieren Markieren Separieren

String Bereich#,0 = "123456789"

Jetzt müßte Bereich so aussehen:

1|2|3|4|5|6|7|8|9|z

jetz neu dimensionieren:
Kompilieren Markieren Separieren

Dim Bereich#,6

Um korrekt zu funktionieren müßte Bereich jetzt so aussehen:

1|2|3|4|5|z

der Speicher dahinter ist jetzt abgetrennt - der gesamte Bereich sollte jetzt so aussehen:

1|2|3|4|5|z7|8|9|z

Profan hat also weder durch Char$ - das bei Überschreiten der Speichergrenze meckert - noch durch String$ Zugriff auf den Speicher hinter Bereich.

Der gesamte Speicherbereich sieht aber immer noch so aus:

1|2|3|4|5|6|7|8|9|z

Sonst hätte Profan keinen Zugriff per String auf den restlichen Teil.
Wenn ich wieder vergrößere, sieht es wieder so aus (sollte):

1|2|3|4|5|z7|8|9|z

Das Nullbyte ist natürlich immer noch drin und jetzt ist der Programmierer gefordert, seine Daten vernünftig auszulesen/einzutragen.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Das Redim kann sich doch aber nicht am string$ oder char$ orientieren.

Auf Speicher, der nicht reserviert ist darf nicht zugegriffen werden - das darf man jetzt hier aber nicht vermischen.

Wenn ein 10 Byte Speicherbereich

HALLO WELT

auf 5 Byte redimensioniert wird, dann muss das Ergebnis unbedingt (und natürlich)

HALLO

sein, und nicht

HALLz

Ich finde XProfan reagiert hier völlig korrekt - ich würde es erwürgen wenn es hier den Speicher selbst verändert.

Was Ihr wollt macht man schliesslich selbst, indem man eben nicht auf 5 sondern 6 dimensioniert und das z-Byte selbst in den Speicher schreibt bevor man z.B. String$ drüberjagt...

Frank
Abbing

iF versteht es noch nicht, herje! Wichtiger ist aber, dass Roland es versteht.
Warum wird bei einem 5 Byte grossen Speicher ein 9 Byte grosser Text in den String kopiert? Ist doch echt nicht sooo schwer...

Frank Abbing

Warum wird bei einem 5 Byte grossen Speicher ein 9 Byte grosser Text in den String kopiert?

Nach welchem Beispiel? Das hier bricht korrekt ab:
Kompilieren Markieren Separieren

 {$cleq}
cls
mem test=5
string test#,0="HALLO WELT"
print string$(test,0)
waitkey
end

Frank Abbing

Wichtiger ist aber, dass Roland es versteht.

Hast Du den Thread verfolgt?

Es ist doch ganz anders. Es ist gefährlich die Funktion String$ auf einen Bereich loszulassen (wenn keine weitere Prüfung enthalten ist) bei dem nicht sichergestellt ist, das er mit einem Nullbyte endet. Dim jedoch hat hier garnichts an Veränderungen des Speicherinhalts zu tun...

Jörg
Sellmeyer

Nein, es ist eben nicht gefährlich, da Dim den Bereich automatisch mit einem NullByte abschließt. Erst ein erneutes Dim macht es gefährlich. Aber ich hab jetzt alles gesagt, was ich dazu zu sagen habe. Soll Roland sich überlegen, ob er Zugriff auf Speicher außerhalb des Programms als Bug oder Feature ansieht.

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...