[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Peter Weseloh]

Peter Weseloh added the comment:

You are right. The format should be 'l'. I overlooked that. In my case the
optional 'buf_size' parameter of 'decompress' is not used anyhow.
Shall I change the patch accordingly?

It work well for me and I now checked the code of PyArg_ParseTuple
(Python/getargs.c) to see what happens. As far as I understand, the given
pointer is casted to a pointer to int if the format is 'i' (line  630) . On
a 64 bit machine this leads to a downcast from a (64 bit) long to a (32 bit)
int, which is OK AFAIK, but I could be wrong.

Thanks for pointing that out,
Peter
2007/11/2, Guido van Rossum <[EMAIL PROTECTED]>:
>
>
> Guido van Rossum added the comment:
>
> I trust that there's a problem, but this can't be right -- the address
> of r_strlen is passed to PyArg_ParseTuple corresponding to an 'i' format
> letter.  That will never do.
>
> --
> assignee:  -> nnorwitz
> nosy: +gvanrossum, nnorwitz
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file8681/unnamed

__
Tracker <[EMAIL PROTECTED]>

__You are right. The format should be 'l'. I overlooked that. In my case 
the optional 'buf_size' parameter of 'decompress' is not used 
anyhow.Shall I change the patch accordingly?It work well for me and 
I now checked the code of PyArg_ParseTuple (Python/getargs.c) to see what 
happens. As far as I understand, the given pointer is casted to a pointer to 
int if the format is 'i' (line  630) . On a 64 bit machine this 
leads to a downcast from a (64 bit) long to a (32 bit) int, which is OK AFAIK, 
but I could be wrong. 
Thanks for pointing that out,Peter2007/11/2, Guido van Rossum [EMAIL PROTECTED]>:
Guido van Rossum added the comment:I trust that there's a 
problem, but this can't be right -- the addressof r_strlen is passed to 
PyArg_ParseTuple corresponding to an 'i' 
formatletter.  That will never do.
--assignee:  -> nnorwitznosy: +gvanrossum, 
nnorwitz__Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue1372>__

___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1376] uu module catches a wrong exception type

[Guido van Rossum]

Guido van Rossum added the comment:

You misunderstand. The try/except is there in case os.stat isn't defined 
or its result doesn't have a st_mode attribute. If the stat operation 
fails due to a problem with the file, there's not much point in proceeding 
since the subsequent open() call would fail the same way.

--
nosy: +gvanrossum
resolution:  -> invalid
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1378] fromfd() and dup() for _socket on WIndows

[roudkerk]

New submission from roudkerk:

The patch adds support for _socket.fromfd() and _socket.socket.dup() on
Windows.  It uses the Win32 DuplicateHandle() function.

The patch is to socketmodule.c an test_socket.py.

--
files: socket_fromfd.patch
messages: 57084
nosy: roudkerk
severity: normal
status: open
title: fromfd() and dup() for _socket on WIndows
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file8682/socket_fromfd.patch

__
Tracker <[EMAIL PROTECTED]>

__

socket_fromfd.patch
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1378] fromfd() and dup() for _socket on WIndows

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error

[Paul Pogonyshev]

New submission from Paul Pogonyshev:

This is apparently because sys.modules contains Unicode (str) keys,
while 'parentname' is an old-style string.  Attached patch seems to fix
it, but I have no idea if it is correct in principle

--
components: Interpreter Core
files: reloading-fix.diff
messages: 57085
nosy: Paul Pogonyshev
severity: normal
status: open
title: reloading imported modules sometimes fail with 'parent not in 
sys.modules' error
versions: Python 3.0
Added file: http://bugs.python.org/file8683/reloading-fix.diff

__
Tracker <[EMAIL PROTECTED]>

__Index: import.c
===
--- import.c(revision 58800)
+++ import.c(working copy)
@@ -2384,7 +2384,7 @@
subname = name;
else {
PyObject *parentname, *parent;
-   parentname = PyString_FromStringAndSize(name, (subname-name));
+   parentname = PyUnicode_FromStringAndSize(name, (subname-name));
if (parentname == NULL) {
imp_modules_reloading_clear();
return NULL;
@@ -2393,7 +2393,7 @@
if (parent == NULL) {
PyErr_Format(PyExc_ImportError,
"reload(): parent %.200s not in sys.modules",
-   PyString_AS_STRING(parentname));
+PyUnicode_AsUTF32String(parentname));
Py_DECREF(parentname);
imp_modules_reloading_clear();
return NULL;
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1379] reloading imported modules sometimes fail with 'parent not in sys.modules' error

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1380] fix for test_asynchat and test_asyncore on pep3137 branch

[Adam Hupp]

New submission from Adam Hupp:

The attached patch resolves test failues in test_asynchat and
test_asyncore.

The asynchat failure was due to interpolating a byte string into a
unicode string using %s.  This resulted in a b'' byte representation
in the final string.  The fix is to use string constants instead of
byte constants.  The result is encoded to bytes later on.

The asyncore failure was due to an explicit isinstance(data, bytes)
check on the result of recv.  The actual type in this case was buffer.
I've removed the check since the next line calls

data.replace(b'\n', b'')

This all should fail for anything thats not a buffer or bytes.

--
components: Library (Lib), Tests
files: pep3137-asynfix.patch
messages: 57086
nosy: hupp
severity: normal
status: open
title: fix for test_asynchat and test_asyncore on pep3137 branch
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8684/pep3137-asynfix.patch

__
Tracker <[EMAIL PROTECTED]>

__

pep3137-asynfix.patch
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1380] fix for test_asynchat and test_asyncore on pep3137 branch

[Christian Heimes]

Christian Heimes added the comment:

Applied in r58831

Thanks!

--
keywords: +patch, py3k
nosy: +tiran
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1381] cmath is numerically unsound

[Andreas Kloeckner]

New submission from Andreas Kloeckner:

This here basically says it all:

>>> import cmath;[cmath.asinh(i*1e-17).real for i in range(0,20)]
[4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16, 4.4408920985006257e-16,
4.4408920985006257e-16, 4.4408920985006257e-16]

The boost.math toolkit at [2] is an implementation that does better in
the above (real-only) aspect.
[2] http://freespace.virgin.net/boost.regex/toolkit/html/index.html

Tim Peters remarks in [1] that basically all of cmath is unsound.
http://mail.python.org/pipermail/python-bugs-list/2001-February/004126.html

I just wanted to make sure that this issue remains on the radar.

--
components: Library (Lib)
messages: 57088
nosy: inducer
severity: normal
status: open
title: cmath is numerically unsound
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1381] cmath is numerically unsound

[Martin v. Löwis]

Martin v. Löwis added the comment:

Can you propose a patch?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1381] cmath is numerically unsound

[Andreas Kloeckner]

Andreas Kloeckner added the comment:

On Samstag 03 November 2007, Martin v. Löwis wrote:
> Martin v. Löwis added the comment:
>
> Can you propose a patch?

Other than point at how boost.math does things, I don't have the time to work 
on this right now, sorry.

Andreas

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Guido van Rossum]

Changes by Guido van Rossum:


Removed file: http://bugs.python.org/file8681/unnamed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1372] zlibmodule.c: int overflow in PyZlib_decompress

[Guido van Rossum]

Guido van Rossum added the comment:

The correct format for a Py_ssize_t is 'n' (at least in the trunk, I
don't have the 2.5 branch handy but I imagine it's the same).

We can figure out the patch from here.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1381] cmath is numerically unsound

[Alan McIntyre]

Alan McIntyre added the comment:

I have to review a few complex math topics for some of my current course
work, so I wouldn't mind taking a look into this.  I can't promise I'll
have the time required to make all of cmath correct (assuming it's as
unsound as claimed), but I'll do what I can.

--
nosy: +alanmcintyre

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com