IDLE RAM auslesen mit file, seek(0,2), write ... Bug?

[Hannes-Spz]

Guten Tag zusammen,

gerade habe ich in einer neu angelegten Datei über das Ende hinausgeschrieben und dann die Datei ausgelesen. Das Resultat war ein Ausschnitt der RAM-Belegung meiner IDLE (pythonw.exe).

Dabei habe ich folgendes getan:

Code: Alles auswählen

import os
os.chdir("D:\\")
fp = open("blahblah", "w+")
fp.readlines()
# []
fp.write("blubb")
fp.tell()
# 5L
fp.seek(0,2)
fp.write("inhalt")
fp.tell()
# 11L
fp.read()
# '\r\x02\x83\x01\x00t\x00\x00|\x02\x00\x83\x01\x00\x04\x03k\x02
# ...
# \x00Set the Wichmann-Hill seed from (x, y, z).\n\n        These must be integers in the range [0, 256).\n

Nun ist mir klar, dass es eine Designentscheidung sein könnte, derartige Dinge zuzulassen, jedoch frage ich mich, ob es das Wert ist, einen Bugtracker-Eintrag dafür hinzuzufügen.

Meine Python-/IDLE-Version ist 2.7.3 und läuft unter Win7x64.
Mit HxD bin ich mit dem letzten Kommentar (set the wichman....) einmal im RAM an ca. x020DE430 und einmal an ca.
x026B13F0 gelandet.

Theoretisch fällt sowas in Buffer-Overflow-Issues (, nach meiner Einschätzung), da jeder, der mit seek(n,2) und eingelesenem n arbeitet, einen Zugriff auf den RAM zulässt. Jedoch würde mich interessieren, was die erfahreneren Python-Nutzer davon halten

Beste Grüße
Johannes

[BlackJack]

@Hannes-Spz: Das hat letztendlich nichts mit Python zu tun. Das reicht einfach nur die Aufrufe an die entsprechende C-API weiter und da gibt es halt solche Fälle. Bei bestimmten Kombinationen von Dateimodi, Lese- und Seek-Operationen ist das Verhalten nicht definiert und man kann Daten aus dem Puffer lesen die „zufällig” sind.

[Hannes-Spz]

@BlackJack: Mir ist schon klar, dass es nur an die C-Api weitergereicht wird und sowas in C Gang und Gebe ist.
Mein Gedanke ist hier nur, ob es nicht vielleicht fundierte Argumente gäbe, es in Python zu unterbinden..?

// hinzugefügt:
Es ist halt nicht in der help(...) ersichtlich, dass seek und write zu derartigen Problemen führen kann und DAS finde ich halb kritisch...
Schließlich steht nach dem read der Inhalt des RAMs in meiner Datei und an dieser Stelle, denke ich, liegt ein Sicherheitsproblem für jeden, der in Dateien schreibt, die ihm nicht gehören.

[BlackJack]

@Hannes-Spz: Also ich benutze `seek()` nicht. Beziehungsweise nur *ganz* selten. Wenn Python also hier versucht irgendwie diese Operationen davor zu sichern dass der Prozess kleine Bruchstücke seines eigenen RAMs sehen kann, passiert das auf Kosten einer Operation, die zumindest ich nicht verwende. Mein favorisierter „Fix” wäre dann also eher ein entsprechender Hinweis in der Dokumentation.

Ich hätte das Problem übrigens auch nicht wenn ich `seek()` verwenden würde:

Code: Alles auswählen

In [1]: !rm test.txt

In [2]: fp = open("test.txt", "w+")

In [3]: fp.readlines()
Out[3]: []

In [4]: fp.write("blubb")

In [5]: fp.tell()
Out[5]: 5L

In [6]: fp.seek(0,2)

In [7]: fp.write("inhalt")

In [8]: fp.tell()
Out[8]: 11L

In [9]: fp.read()
Out[9]: ''

Vielleicht sollte man da eher einen Fehlerbericht bei Microsoft einreichen als bei Python.

[Hannes-Spz]

Ah, also wahrscheinlich kein MS-User...
Ich wollte eigentlich einen Fehler provozieren, der auf dem unter folgender URL gelistetem Bug basiert:
[url=https://mail.python.org/pipermail/pytho ... 29886.html]python-Bugs-1252149 - IOError after normal write[/url]

Aber danke für die Meinung, einen Eintrag in der Dokumentation würde ich schon sehr begrüßen, aber wo sollte man sowas anmerken?

// anderes Thema @BlackJack:
Jedoch hast du jetzt meine Neugier geweckt - wie sonst würdest du in großen Dateien hin- und herspringen, um Daten blockweise zu lesen/schreiben?

[BlackJack]

@Hannes-Spz: Ich würde es bei Python im normalen Bugtracker melden falls es keine bessere Stelle gibt. Es scheint allerdings schon einen Bugreport dafür zu geben: http://bugs.python.org/issue5677

In grossen Dateien wo wahlweise Blöcke gelesen oder geschrieben werden müssen, würde ich natürlich auch `seek()` verwenden. Das ist halt bloss ein Szenario welches bei mir nicht wirklich häufig vorkommt. Üblicherweise gibt es immer eine Bibliothek, die das für mich schon hinter einer schönen API versteckt hat.