[ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32
SourceForge.net
noreply at sourceforge.net
Sun Jan 1 07:06:43 CET 2006
Bugs item #1394612, was opened at 2005-12-31 19:06
Message generated for change (Settings changed) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Cory Dodt (corydodt)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'Plus' filemode exposes uninitialized memory on win32
Initial Comment:
(Note: I'm using cygwin zsh, hence the prompts. I am
using standard, python.org Python for these tests.)
% 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()
>>>
----------------------------------------------------------------------
>Comment By: Tim Peters (tim_one)
Date: 2006-01-01 01:06
Message:
Logged In: YES
user_id=31435
This is actually pilot error (not a bug!), although it's
subtle: Python uses the platform C I/O implementation, and
in standard C mixing reads with writes yields undefined
behavior unless a file-positioning operation (typically a
seek()) occurs between switching from reading to writing (or
vice versa); here from the C standard:
When a file is opened with update mode (â+â as the
second or third character in the above list of mode
argument values), both input and output may be
performed on the associated stream. However, output
shall not be directly followed by input without an
intervening call to the fflush function or to a file
positioning function (fseek, fsetpos, or rewind), and
input shall not be directly followed by output
without an intervening call to a file positioning
function, unless the input operation encounters
end-of-file.
In other words, the result of running your sample code is
undefined: nothing is guaranteed about its behavior, which
both can and does vary across platforms.
If you want defined behavior, then, for example, add
>>> f.seek(0)
between your write() and read() calls.
----------------------------------------------------------------------
Comment By: Clinton Roy (clintonroy)
Date: 2006-01-01 00:38
Message:
Logged In: YES
user_id=31446
Hi Cory, I don't think r+ mode will create the file if it
doesn't exist, so at a guess I think what you're seeing is
the actual contents of a file named foo that are on the
disk, not junk. If you delete the file foo and run your test
again, you should get an error to that effect.
cheers,
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1394612&group_id=5470
More information about the Python-bugs-list
mailing list