[ 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