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

[SourceForge.net]

Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by splitscreen
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: splitscreen (splitscreen)
Assigned to: Tim Peters (tim_one)
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: splitscreen (splitscreen)
Date: 2006-04-01 21: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 20: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: splitscreen (splitscreen)
Date: 2006-04-01 19: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: splitscreen (splitscreen)
Date: 2006-04-01 14: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 07: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 18: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