[ python-Bugs-1238681 ] freed pointer is used in longobject.c:long_pow()

[SourceForge.net]

Bugs item #1238681, was opened at 2005-07-15 07:06
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&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.4
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Luke (luked)
Assigned to: Tim Peters (tim_one)
Summary: freed pointer is used in longobject.c:long_pow()

Initial Comment:
See in the following code snippet (from the end of the
long_pow function in longobject.c) that "b" is used
after it has been freed:

 Done:
Py_XDECREF(a);
Py_XDECREF(b);
Py_XDECREF(c);
Py_XDECREF(temp);
if (b->ob_size > FIVEARY_CUTOFF) {
for (i = 0; i < 32; ++i)
Py_XDECREF(table[i]);
}
return (PyObject *)z;
}

The error exists in 2.4.1 and on CVS trunk.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-18 09:24

Message:
Logged In: YES 
user_id=1188172

And backported as Objects/longobject.c r1.165.2.2.

--

Comment By: Tim Peters (tim_one)
Date: 2005-07-18 01:47

Message:
Logged In: YES 
user_id=31435

Eww -- gross.  Thanks for the report!  Repaired (along with a 
another long_pow() coding error) in:

Misc/NEWS 1.1319
Objects/longobject.c 1.169

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-07-15 07:26

Message:
Logged In: YES 
user_id=80475

Tim, I believe this one belongs to you (checkin 1.163 on
8/30/2004).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238681&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-957505 ] SocketServer module documentation misleading

[SourceForge.net]

Bugs item #957505, was opened at 2004-05-20 18:42
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&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: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jon Giddy (jongiddy)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: SocketServer module documentation misleading

Initial Comment:
The Python Library Reference page for the SocketServer
module refers to RequestHandlerClass as though it was
the name of an actual class. Actually, it should be
either "request handler class" or "BaseRequestHandler".

Secondly, in the second para of the BaseRequestHandler
handle() method description, StreamRequestHandler and
DatagramRequestHandler are referred to as mix-in
classes when they are in fact subclasses of
BaseRequestHandler.

This error is also present in the comments at the start
of the module.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-18 09:39

Message:
Logged In: YES 
user_id=1188172

Thanks for the suggestions. Your first point has already
been clarified by adding more explanation to the docs, the
second point I have corrected in
Doc/lib/libsocksvr.tex r1.20, r1.18.4.2, Lib/SocketServer.py
r1.40, r1.37.4.1.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=957505&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-850238 ] unclear documentation/missing command?

[SourceForge.net]

Bugs item #850238, was opened at 2003-11-27 14:11
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&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: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andreas Kostyrka (yacc143)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: unclear documentation/missing command?

Initial Comment:
Hi!

The documentation of \declaremodule
(http://www.python.org/doc/2.3.2/doc/module-markup.html)
misses one important thing:

It only works as such if you use one \section per module.
(I had some fun LaTeX debugging to find it)

It should also be noted, that perhaps an extra command
to call [EMAIL PROTECTED], something like \endmodule, this way the
author could specify which part of the file pertains to
certain module.

Alternativly, perhaps \declaremodule should flush out
any module info that is already entered?

Andreas

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-18 10:05

Message:
Logged In: YES 
user_id=1188172

Added a remark that each module should be documented in its
own \section.

Doc/doc/doc.tex r1.94, 1.90.2.3.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-755617 ] os module: Need a better description of " mode"

[SourceForge.net]

Bugs item #755617, was opened at 2003-06-17 02:13
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755617&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: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Shomphe (mshomphe)
>Assigned to: Reinhold Birkenfeld (birkenfeld)
Summary: os module: Need a better description of "mode"

Initial Comment:
The page  says the following 
about the function os.chmod:

chmod(path, mode) 
Change the mode of path to the numeric mode. 
Availability: Unix, Windows. 

The "mode" values are unclear.  It turns out that the 
UNIX file permission set (e.g., 0666 for read/writeable) 
works with the Windows set (where 0666 translates to  
33206).

Is it possible to describe the file permissions in more 
detail in the documentation at this point?

Attached is an email thread discussing this 
documentation issue.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-18 10:17

Message:
Logged In: YES 
user_id=1188172

Added this note to the chmod docs:

Although Windows supports chmod, you can only set the
file's read-only flag with this function (via the
\code{S_IWRITE}
and \code{S_IREAD} constants or a corresponding integer value).
All other bits are ignored.

Doc/lib/libos.tex r1.164, r1.146.2.10.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-05 20:28

Message:
Logged In: YES 
user_id=1188172

I think the wording suggested by logistix would be a good
addition to the docs.

--

Comment By: logistix (logistix)
Date: 2003-06-17 21:31

Message:
Logged In: YES 
user_id=699438

Something like:

"NOTE: Although Windows supports chmod, it incorporates 
much different functionality than a typical Unix user would 
expect.  Please refer to Microsoft’s documentation for more 
details."

would be nice.

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 17:18

Message:
Logged In: YES 
user_id=531881

Tim-

I captured what Matthew Shomphe recommended into patch 755677
(http://www.python.org/sf/755677).  Hope this helps.

-c

--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 16:49

Message:
Logged In: YES 
user_id=31435

Then please suggest the actual text you want to see in the 
docs.  I can't do it for you (for example, chmod has always 
done exactly what I've wanted it to do on Windows -- but 
then I've never wanted to do anything with it on Windows 
beyond fiddling the readonly bit).

--

Comment By: logistix (logistix)
Date: 2003-06-17 07:35

Message:
Logged In: YES 
user_id=699438

All I'm saying is that although chmod is valid windows call, it 
will not produce the effect that most users expect.  There's 
no harm in calling it, but it's not going to accomplish what 
most users want it to do.  This information is more important 
to a user than other inconsistencies in the Windows 
implementation.  (i.e. os.stat returning a value that is 
different than chmod set)

--

Comment By: Christopher Blunck (blunck2)
Date: 2003-06-17 05:37

Message:
Logged In: YES 
user_id=531881

see patch 755677

sheesh neal, you couldn't patch this?  ;-)


--

Comment By: Tim Peters (tim_one)
Date: 2003-06-17 05:28

Message:
Logged In: YES 
user_id=31435

Well, let's not overreact here -- MS's _chmod simply calls the 
Win32 SetFileAttributes(), and the only thing it can change is 
the FILE_ATTRIBUTE_READONLY flag.  That's all part of 
Windows base services, and makes sense on FAT too.

--

Comment By: logistix (logistix)
Date: 2003-06-17 04:51

Message:
Logged In: YES 
user_id=699438

Realistically, you should NEVER intentionally use chmod to set 
file permissions on Windows.  The FAT filesystem has no 
permissions, and NTFS has ACLs which are much too complex 
to map to a chmod style call.  MS only has chmod support so 
they can claim some level of posix compliance.

I'm not saying you should drop the ability to call os.chmod on 
windows, but perhaps the docs should say that its not the 
recommended way of doing things.  Unfortunately, there's not 
a recommended way of setting security that'll work on all 
Windows platforms 

[ python-Bugs-1231069 ] ioctl has problem with -ive request codes

[SourceForge.net]

Bugs item #1231069, was opened at 2005-07-01 17:24
Message generated for change (Comment added) made by barry-scott
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Michael Hudson (mwh)
Summary: ioctl has problem with -ive request codes

Initial Comment:
On Linux many ioctl request code values cannot be
passed to ioctl
because it assumes that the values are signed ints.
Value with the
top bit set 0x800 are common.

Changing the PyArg_ParseTuple calls to use "I" instead
of "i"
fixes the problem.

This may well also be the issue with bug 1112949
"ioctl has problems on 64 bit machines".

The attached patch fixes the problem in 2.4.1 and was
tested on FC4.


--

>Comment By: Barry Alan Scott (barry-scott)
Date: 2005-07-18 11:57

Message:
Logged In: YES 
user_id=28665

I've messed up attchments on SF before but
the patch downloads for me.

Barry


--

Comment By: Michael Hudson (mwh)
Date: 2005-07-03 15:50

Message:
Logged In: YES 
user_id=6656

The patch seems to be empty (!?)

Good idea, although not goo enough for me to fight CVS over dialup...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1223238 ] race in os.makedirs()

[SourceForge.net]

Bugs item #1223238, was opened at 2005-06-18 18:37
Message generated for change (Comment added) made by yorick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&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: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: race in os.makedirs()

Initial Comment:
os.makedirs() can fail if one of its components is
created while it is running (perhaps by another
process). This is because it checks for each directory
if it exists before creating it.

This is bad programming style. A correct implementation
would just call mkdir() on each directory (starting
with the rightmost, probably) and ignoring any EEXIST
error. This would not only fix the bug, it would also
be faster (fewer syscalls).

The patch is simple, but there is a wart in the design:
os.makedirs() throws an error if the (rightmost)
directory already exists, although by calling this
function the user has clearly indicated that she wants
the directories to be created if they don't exist and
have no complaints otherwise.

This leads to code like:

try:
os.makedirs(path)
except OSError:
pass

which is doubly bad because it hides the race condition!

So, before I submit a patch, should we:
a) just fix this bug but keep the old design
b) fix this bug, and don't throw an error if the dir exists

or maybe do a) for the next 2.4.x bugfix release and b)
in 2.5?


--

>Comment By: Mattias Engdegård (yorick)
Date: 2005-07-18 14:08

Message:
Logged In: YES 
user_id=432579

Whether the dir creation is done right-to-left or
left-to-right is less important. If the expected usage
pattern is that most of the directories already exist, then
right-to-left may be faster, otherwise left-to-right is. One
advantage with the former is its slightly simpler code (no
need to check for ENOENT).

>current 2.4 code does not return an error if the directory
exists,
>the patch must not change that behavior.

You mean the contrary? From what I can see of the 2.4 code,
it throws an error if the directory exists. This is almost
never what you want, so I strongly doubt fixing that
misfeature in 2.5 would break anything. I'm happy with the
suggested patch for 2.5 in #1239890.


--

Comment By: Nir Soffer (nirs)
Date: 2005-07-17 23:10

Message:
Logged In: YES 
user_id=832344

current 2.4 code does not return an error if the directory exists, the patch 
must not change that behavior.

It will not be a good idea to change that behavior in 2.5 or any version, it 
can break lot of code.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 21:56

Message:
Logged In: YES 
user_id=1188172

See patch #1239890.

--

Comment By: Mattias Engdegård (yorick)
Date: 2005-06-25 23:11

Message:
Logged In: YES 
user_id=432579

I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since 
programs susceptible to the bug must use some kind of work-around in 
2.4.x (x < 2) anyway.
What I am using right now is:

def makedirs(name, mode=0777):
try:
os.mkdir(name, mode)
return
except OSError, err:
if err.errno == errno.EEXIST:
return
if err.errno != errno.ENOENT:
raise
makedirs(os.path.dirname(name), mode)
makedirs(name, mode)

This is compact and elegant, but relies on mkdir producing the correct 
errno values, which should be true for all platforms I'm aware of. It could 
also theoretically loop infinitely in bizarre cases but I don't see how that 
ever could happen.


--

Comment By: Neil Schemenauer (nascheme)
Date: 2005-06-18 19:43

Message:
Logged In: YES 
user_id=35752

I vote to fix the design for 2.5.  Backporting the minimal
fix to 2.4 would be optional, IMO.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com