XProfan

- Seite 3 -

Jörg Sellmeyer

Soll Roland sich überlegen, ob er Zugriff auf Speicher außerhalb des Programms als Bug oder Feature ansieht.

Ich würde sagen, dass Zugriff auf unreservierten Speicher, durch den Programmierer zu vermeiden ist.

Frank
Abbing

Ja, Jörg, es ist ein Kreuz mit dem iF. Proggt komplizierte Vorgänge, aber kapituliert bei den einfachsten Dingen...

Ausschlaggebend ist aber Roland.

RGH

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

Gruß
Roland

@Frank: Weshalb ich Deine Aussage nicht so recht einordnen kann - was genau übersehe ich eigentlich?

Jörg
Sellmeyer

Ich glaube, wir müssen nicht klären was String$ macht, sondern was Dim macht/machen sollte.

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

Speicher reservieren und Größe ändern. (Und jetzt noch ein NULL-Byte hinten anhängen? Wenn ich auf eine Strukturgröße zurückändere würde das letzte Byte einfach "übermalt"?)

Jörg
Sellmeyer

Was heißt zurückändern. Wenn Du den Bereich nach dem Verkleinern wieder vergrößerst, hast Du keinen Anspruch darauf, daß der Inhalt noch so ist wie vorher. Der kann ja durch zig andere Prozesse überschrieben sein.

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

Zurückändern natürlich nicht im Sinne von Vergrößern - sondern verkleinern.

Jörg
Sellmeyer

Ok, jetzt weiß ich glaube ich, wo das Problem liegt. Ich habe oben Dim B#,10 geschrieben und 1-9 + NULL geschrieben. Mit einem Nullbyte hinten an den Speicherbereich angehängt könntetst Du Dich aber hoffentlich arrangieren, oder? Es sollte so ausehen:

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

und Dim Bereich#,6 macht dann

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

aus dem Speicherbereich. Einverstanden?

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

Auf gar keinen Fall sollte Roland Speicher bemalen unklarer Zuordnung, dass kann sogar crashen.

Wenn überhaupt könnte Roland +1 reservieren, hinten eine 0 reintun, dann auf +0 reservieren. Die 0 "hinten" dran wäre dann aber immer noch inkonsistent - also auch Quatsch.

Jörg
Sellmeyer

Naja - irgendwie ähnlich muß er es ja auch beim ersten Mal machen...

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

RGH

Auch wenn ich im Urlaub bin:

Dim reserviert Speicher, beschreibt ihn aber nicht. Es wird also auch kein Null-Byte eingefügt.

Was vermutlich irritiert, ist die Tatsache, dass sowohl String$() als auch Char$() aus Tempogründen die Bereichsgrenzen nicht überprüfen. Hier kann man sicher für kommende XProfanversionen diskutieren, ob eine solche Überprüfung sinnvoll ist oder nicht.

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

Aber wenn ich einen Bereich dimensioniere, ist doch das letzte Byte immer erstmal ein Nullbyte:
Kompilieren Markieren Separieren

Cls
Declare B#
Dim B#,10
Print SizeOf(B#)
Print Len("123456789")
Char B#,9,"z"
String B#,0= "123456789"
String B#,0= "0123456789" das knallt
Print String$(B#,0)
Char B#,9,"z"
Print String$(B#,0)
Dim B#,6
String B#,0="98765"
Print String$(B#,0)
Dispose B#
WaitInput

Also ist es der Befehl "String", der verhindert, das auf das letzte Byte geschrieben wird? Leztlich ist es mir egal. Lieber nicht das Tempo drosseln. Wenn die Syntax in sich stimmig ist, ists ok. Ich dachte, das Dim regelt das irgendwie. So stimmt die Systematik.

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