[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes

[SourceForge.net]

Bugs item #1462152, was opened at 2006-03-31 10:02
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Georg Brandl (gbrandl)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

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

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 21:19

Message:
Logged In: YES 
user_id=31435

This is still ;-) fine with me.  There doesn't seem to be a
test in fileobject2.diff.  WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three).  It should state that
this requirement is new in Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 06:14

Message:
Logged In: YES 
user_id=1126061

Yeah, your patch looks much better.

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 04:15

Message:
Logged In: YES 
user_id=849994

splitscreen: your patch was incomplete and could have
overwritten memory.

tim_one: Attaching new patch implementing what I proposed in
my comment below.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 16:59

Message:
Logged In: YES 
user_id=1126061

Ok, uploading latest patch, not quite sure I've hit the mark
here.

Please review.


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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 15:43

Message:
Logged In: YES 
user_id=849994

Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:32

Message:
Logged In: YES 
user_id=1126061

Ignore my question, it's for "universal newlines", right? 

Have I understood your proposal correctly in that you want
to remove the 'U' from the mode? 

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

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 09:14

Message:
Logged In: YES 
user_id=1126061

That seems sensible. What does a mode containing 'U' mean
anyway?

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

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 02:08

Message:
Logged In: YES 
user_id=849994

Instead of this patch, I'd rather like check_the_mode to

* remove any 'U' from the mode string
* if 'U' was found:
  * error out if the new string begins with 'w' or 'a'
  * add a 'r' and 'b' if it isn't already given
* if not:
  * error out if the string doesn't begin with 'w', 'r', 'a'

What do you think of it?

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

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 13:03

Message:
Logged In: YES 
user_id=31435

There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed.  I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").

All that said, I'm in favor of this patch ;-).  However, if
it goes in two things are needed:

1. The error message should be more informative, like

   PyErr_Format(PyExc_ValueError, "mode argument must "
     "begin with 'w', 'r', or 'a', not '%.200s'", mode);

2. The Python docs should change to match (i.e., the
   manual should document this new restriction on mode
   strings).

WRT the test case, it's more natural to write, e.g.,

    TESTFN in s

than

    s.find(TESTFN) != -1

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470