[ python-Bugs-1394612 ] 'Plus' filemode exposes uninitialized memory on win32

[SourceForge.net]

Bugs item #1394612, was opened at 2005-12-31 19:06
Message generated for change (Comment added) made by kuran
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: Jp Calderone (kuran)
Date: 2006-01-01 17:08

Message:
Logged In: YES 
user_id=366566

I think Cory was aware of the underlying requirement to
interpose a seek operation between the write and read
operations, but was concerned about the consequences of not
doing so.  Python normally protects one from doing things
that are *too* dangerous: I guess it's unclear to him (and
perhaps others) whether the current behavior of file is just
(relatively) obscure or if it could lead to real problems
(exposing sensitive data, crashing the process).  It seems
like the latter is somewhat unlikely in practice, but since
the behavior is unspecified, it seems like it *could* happen.

I guess since Tim closed this, he thinks it's not too
dangerous.  In this case, the documentation could probably
stand to be improved somewhat.  The section
(<http://python.org/doc/lib/built-in-funcs.html#built-in-funcs>)
that documents the various modes which can be used to open a
file could updated to include a warning along the lines of
that in the C standard.  It should probably explicitly state
which file methods can be used to satisfy this requirement,
since it's not clear otherwise except by reading the
implementation of the file type (one could guess, from
<http://python.org/doc/lib/bltin-file-objects.html#bltin-file-objects>
that file.flush() and file.seek() are suitable, but the
documentation for these only says "like stdio ...", so you
can't be completely sure).


----------------------------------------------------------------------

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