[issue43903] round() produces incorrect results with certain values
New submission from Olli : When rounding numbers with round(), middle values at with even base number are rounded in wrong direction. Python 3.9.1 (default, Feb 3 2021, 07:38:02) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin MacBook Pro (13-inch, 2017, Two Thunderbolt 3 ports) macOS 11.2.3 (20D91), Darwin 20.3.0 to reproduce (wrong results marked with "*"): floats: >>> for i in range(0, 10): ... i /= 2 ... print(i, '->', round(i)) ... 0.0 -> 0 0.5 -> 0 * 1.0 -> 1 1.5 -> 2 2.0 -> 2 2.5 -> 2 * 3.0 -> 3 3.5 -> 4 4.0 -> 4 4.5 -> 4 * and for ints: >>> for i in range(50, 1000, 50): ... print(i, '->', round(int(i), -2)) ... 50 -> 0 * 100 -> 100 150 -> 200 200 -> 200 250 -> 200 * 300 -> 300 350 -> 400 400 -> 400 450 -> 400 * 500 -> 500 550 -> 600 600 -> 600 650 -> 600 * 700 -> 700 750 -> 800 800 -> 800 850 -> 800 * 900 -> 900 950 -> 1000 -- components: Library (Lib) messages: 391499 nosy: MrBlueSkies priority: normal severity: normal status: open title: round() produces incorrect results with certain values type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43903] round() produces incorrect results with certain values
Olli added the comment: Just because incorrect results are documented, that doesn't mean the current implementation could not be improved. More over, Python 2.7.16 on the same machine produces expected results: Python 2.7.16 (default, Dec 21 2020, 23:00:36) [GCC Apple LLVM 12.0.0 (clang-1200.0.30.4) [+internal-os, ptrauth-isa=sign+stri on darwin >>> for i in range(0, 10): ... i = float(i) / 2 ... print i, '->', round(i) ... 0.0 -> 0.0 0.5 -> 1.0 1.0 -> 1.0 1.5 -> 2.0 2.0 -> 2.0 2.5 -> 3.0 3.0 -> 3.0 3.5 -> 4.0 4.0 -> 4.0 4.5 -> 5.0 While exactly same code on Python 3.9.1 on same platform: Python 3.9.1 (default, Feb 3 2021, 07:38:02) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin >>> for i in range(0, 10): ... i = float(i) / 2 ... print(i, '->', round(i)) ... 0.0 -> 0 0.5 -> 0 1.0 -> 1 1.5 -> 2 2.0 -> 2 2.5 -> 2 3.0 -> 3 3.5 -> 4 4.0 -> 4 4.5 -> 4 -- ___ Python tracker <https://bugs.python.org/issue43903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46673] Py_BuildValue tuple creation segfaults in python3.9..3.11
New submission from Olli Lupton :
The following function, compiled and linked into a shared library, segfaults
when called from Python:
```
#define PY_SSIZE_T_CLEAN
#include
extern "C" PyObject* my_func() {
return Py_BuildValue("(O)", Py_None);
}
```
called using ctypes:
```
from ctypes import CDLL
h = CDLL('./libtest.so’)
h.my_func()”
```
crashes with a stacktrace
```
Program received signal SIGSEGV, Segmentation fault.
_PyObject_GC_TRACK_impl (filename=0x7fffed7ab1b0 "src/Objects/tupleobject.c",
lineno=36, op=(0x0,)) at src/Include/internal/pycore_object.h:43
(gdb) bt
#0 _PyObject_GC_TRACK_impl (filename=0x7fffed7ab1b0
"src/Objects/tupleobject.c", lineno=36,
op=(0x0,)) at src/Include/internal/pycore_object.h:43
#1 tuple_gc_track (op=0x7fffe5e42dc0) at src/Objects/tupleobject.c:36
#2 PyTuple_New (size=) at src/Objects/tupleobject.c:124
#3 PyTuple_New (size=size@entry=1) at src/Objects/tupleobject.c:100
#4 0x7fffed7031eb in do_mktuple (p_format=0x7fffa8d0,
p_va=0x7fffa8d8, endchar=, n=1, flags=1) at
src/Python/modsupport.c:259
#5 0x7fffed703358 in va_build_value (format=,
va=va@entry=0x7fffa918, flags=flags@entry=1) at src/Python/modsupport.c:562
#6 0x7fffed7036d9 in _Py_BuildValue_SizeT (format=) at
src/Python/modsupport.c:530
#7 0x7fffedae6126 in my_func () at test.cpp:4
#8 0x7fffedaf1c9d in ffi_call_unix64 () from libffi.so.7
#9 0x7fffedaf0623 in ffi_call_int () from libffi.so.7
…
```
this is reproducible on RHEL7 (Python 3.9.7 built with GCC 11.2) and macOS
(Python 3.9.10, 3.10.2 and 3.11.0a4 installed via MacPorts).
It does not crash with Python 3.8, I tested on RHEL7 (Python 3.8.3 built with
GCC 9.3.0) and macOS (Python 3.8.12 installed via MacPorts).
This is meant to be a minimal example. It seems to be important that
`Py_BuildValue` is returning a tuple, but the size of that tuple is not
important.
`"O"` and `Py_None` are also not important, it still crashes with `"i"` and
`42`.
The definition of `PY_SSIZE_T_CLEAN` also does not seem to be important; the
only obvious difference it makes is whether I see `_Py_BuildValue_SizeT` or
`Py_BuildValue` in the backtrace.
This seems to be a bit of an unlikely bug, so apologies in advance if I have
missed something obvious. I tried to be thorough, but I do not have a lot of
experience working with the Python C API.
--
components: C API, Extension Modules, ctypes
messages: 412725
nosy: olupton
priority: normal
severity: normal
status: open
title: Py_BuildValue tuple creation segfaults in python3.9..3.11
type: crash
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46673>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46673] Py_BuildValue tuple creation segfaults in python3.9..3.11
Olli Lupton added the comment: With apologies for the noise, I realise that the posted example does not handle the GIL correctly. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli added the comment: Would it be practical to have a trivial compilation test to see if we are capable of using GCC with -mno-cygwin and if so, use it, otherwise drop off? I think GNU autotools uses a similar strategy for detecting compiler capabilities. -- nosy: +Seppo.Yli-Olli ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12430] Pip fails to fetch from mirror if PyPi checksum times out
New submission from Seppo Yli-Olli : Checksums need to be mirrored as well, otherwise having mirrors is a waste of money because PyPi main server being slow ends up with whole download failing. If this is the wrong bug tracker, please advice me to the right one so this can be resolved. -- components: None files: pip.log messages: 139357 nosy: Seppo.Yli-Olli priority: normal severity: normal status: open title: Pip fails to fetch from mirror if PyPi checksum times out versions: Python 2.7 Added file: http://bugs.python.org/file22507/pip.log ___ Python tracker <http://bugs.python.org/issue12430> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12430] Pip fails to fetch from mirror if PyPi checksum times out
Changes by Seppo Yli-Olli : -- type: -> feature request ___ Python tracker <http://bugs.python.org/issue12430> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
New submission from Seppo Yli-Olli : MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else than in the end. The comment in https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504 clearly shows that Python has the assumption that this specification is actually correct. However, Microsoft is violating it eg in https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you from reading that registry key in Python at all. This is a list which is treated as pairs: """ foo meep bar """ so you can have empty items which in Windows semantics means "remove this file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing relaxing Python registry handling semantics because it's clearly Microsoft isn't following this either -- messages: 310202 nosy: nanonyme priority: normal severity: normal status: open title: Make REG_MULTI_SZ support PendingFileRenameOperations ___ Python tracker <https://bugs.python.org/issue32587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
Seppo Yli-Olli added the comment: I don't personally know enough of CPython (I barely know enough C) to do the patches but I'd just comment that as this might increase complexity of implementation and wide char API's are used, it might be prudent to make sure the new implementation works with some more exotic input than fits into ASCII. PendingFileRenameOperations can contain any valid Windows path. Microsoft also warns that the end null byte can be redacted in some cases by the party storing the data. -- ___ Python tracker <https://bugs.python.org/issue32587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli added the comment:
Since Renata's ERRATA was unclear to whether or not this was *actually* removed
(please point to a changeset if the option was removed):
If the option is no longer required by Pidgin and that was the original reason
to have it in the first, there's really no reason *not* to remove this, no?
Eg this code
> int main() { return 0; }
Fails to compile on MingW gcc 4.6 and 4.7 when passing -mno-cygwin to gcc. The
solution that distutils does not work with current versions of MingW (and GCC)
for good is unacceptable so the only working solution is removal of no-cygwin.
Just that GCC 4.4 would support the flag does not change this bug one way or
the other.
--
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli added the comment: ERRATA Misunderstood the meaning of ERRATA, please ignore my last post. Roumen Petrov wrote: > Where is written that compiler is gcc ? Yes this is current distutils > code but please review my set of patches I kinda like the using --target-help for finding out if -mno-cygwin is supported assuming --target-help is supported by all GCC's. I disliked the version-based approach since back from 2011 since it seems fragile to me. I'm noo sure if it falls into the category of lightweight checks Eric asked for in #msg146499 but at least more lightweight than my proposal of trying to compile a sample program with the compiler. -- ___ Python tracker <http://bugs.python.org/issue12641> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
