New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Plus' filemode exposes uninitialized memory on win32 #42745
Comments
(Note: I'm using cygwin zsh, hence the prompts. I am % echo abcdef > foo
% python
Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> f = file('foo','r+b')
>>> f.write('ghi')
>>> f.read()
'\x00x\x01\x83\x00\xe8\x03\x00\x00\xff\xff\xff\xff\x00\x00\x00\x00e\x00\x00i\x01
\x00d\x00\x00\x83\x01\x00Fd\x01\x00S\x00S\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
0\x00\x00\x00[...lots and lots and lots of
uninitialized memory deleted...]\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
x00\x00\x00\x00abcdef\n'
>>> f.close()
>>> |
Logged In: YES Hi Cory, I don't think r+ mode will create the file if it cheers, |
Logged In: YES This is actually pilot error (not a bug!), although it's
In other words, the result of running your sample code is If you want defined behavior, then, for example, add
between your write() and read() calls. |
Logged In: YES I think Cory was aware of the underlying requirement to I guess since Tim closed this, he thinks it's not too |
Logged In: YES There's nothing Python can do about this short of I'll note that I'm not bothered by it. It's one of those |
Logged In: YES Tim - at a minimum this should be documented; even if it's Either here, or perhaps in section 2.3.9, a clear I'm also dubious that this exposed memory is innocuous, but |
Logged In: YES i think there's a bit of confusion here as to what exactly ansi c says that for files fopen()ed for reading and writing the behaviour we are seeing using python file objects: with glibc:
1. read + write + read result in no data being returned by
the last read. this is the case regardless of whether we do
f.readlines()+f.writelines()+f.readlines() or
f.read()+f.write()+f.read(). this does not comnform to
expected behaviour (as per ansi c and glibc fopen(3)),
because at least in the latter (read() with no size
parameter) case, python docs promise to stop at EOF,
triggering the exception ansi c/glibc make to the
intervening synchronization with file positioning requirement.
with msvscrt:
1. in the f.read()+f.write()+f.read() case, the f.write()
generates an IOError. this deviates from ansi c, but is in
line with msdn docs.
2. in the f.readlines()+f.writelines()+f.readlines() case,
you see the type of results quoted in the bug submission.
this deviates from ansi c if you expect readlines() to read
EOF, but is still in line with msdn docs. there are 3 issues here:
to recap, the real issue, imo, seems to be that we shouldn't there are 4 options for dealing with this:
the latter option, from the perspective of "this is exactly cheers, |
Logged In: YES paul_g's option #1 is the only that takes no work, so is the BTW, I don't understand: """1. in the f.read()+f.write()+f.read() case, the f.write() All behavior in that case is explicitly not defined by ANSI |
Logged In: YES i'll comment about the rest later, but re not understanding: here is what ansi says: "If the file has been opened for note the last sentence. python docs say that f.read() with so glibc promises ansi c compliance, but does not deliver. make sense? -p |
Logged In: YES "make sense?" So far as it goes, yes -- thanks. At a higher level ;-), Pushing beyond that doesn't interest me. Note that Python's file_read() (in fileobject.c) is already |
Logged In: YES BTW, the standard actually says:
In your f.read() + f.write() example, that doesn't happen. On Windows, that appears to work fine, too: C:\Code>echo abc > foo
C:\Code>\python24\python.exe
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32
...
>>> f = open('foo', 'r+b')
>>> f.read()
'abc \r\n'
>>> f.read() # _this_ read "encounters EOF"
''
>>> f.write('xyz')
>>> f.seek(0)
>>> f.read()
'abc \r\nxyz'
>>> |
Logged In: YES i haven't ecnountered this edge case either, in my c days or this issue actually cropped up in a unit test in twisted the explanation of read() and why this isn't working as i "Read at most size bytes from the file (less if the read this states, absolutely unequivocally, that the first read as i stated previously, the correct solution in my view is as such, this becomes a documentation issue. users should be make sense? -p |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: