Changes by Stefan Krah :
--
nosy: +lemburg
priority: normal -> low
type: -> enhancement
versions: +Python 3.7
___
Python tracker
<http://bugs.python.org/i
Stefan Krah added the comment:
It's a useful warning, but I find it annoying to add 20 "fall through"
comments. I may add a pragma at some point.
--
___
Python tracker
<http://bugs.pyt
Changes by Stefan Krah :
--
pull_requests: +2764
___
Python tracker
<http://bugs.python.org/issue30923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset 72b543308ee3087e3fa247981f5cb4be1138c515 by Stefan Krah in branch
'master':
bpo-30923: Suppress fall-through warnings in libmpdec. (#2698)
https://github.com/python/cpython/commit/72b543308ee3087e3fa247981f5cb4
Stefan Krah added the comment:
Hmm, that took about 20 min to commit a 3 line diff. Now I'm watching the
buildbots...
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Stéphane, if you want the libmpdec change cherry picked and are willing to do
the (significant) work of backporting, I'll merge it.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
Well, it's not a bug, but perhaps it is annoying for users of this gcc version
if they compile 3.6 often.
Actually, I think gcc should not include this warning in -Wextra. It's
something that could be run manually before a release.
I'd vote
Stefan Krah added the comment:
We can check for the version, but all versions of gcc that I tested
accept and ignore -Wno-implicit-fallthrough, even though they don't
actually have -Wimplicit-fallthrough.
Of course they choke on -Wimplicit-fallthro
Stefan Krah added the comment:
I think the fall-through blog notes are slightly overstated. :-)
"The switch fallthrough has been widely considered a design defect in C."
It's an important feature.
--
___
Python tracker
<http
Stefan Krah added the comment:
Look at Include/longobject.h and
https://docs.python.org/3/library/stdtypes.html?highlight=bit_length#int.bit_length
.
--
nosy: +skrah
___
Python tracker
<http://bugs.python.org/issue31
Stefan Krah added the comment:
Thank you for your expertise.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Stefan Krah added the comment:
Yes, please add libmpdec to the ignored files.
--
___
Python tracker
<http://bugs.python.org/issue31221>
___
___
Python-bugs-list m
Stefan Krah added the comment:
Thanks. I tried to revert it, but got:
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: error: 2 of 2 required status checks are expected.
To https
Changes by Stefan Krah :
--
pull_requests: +3166
___
Python tracker
<http://bugs.python.org/issue30923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
So I installed gcc-7.2.0 from source. Hilariously compiling gcc *itself*
emits fallthrough warnings!
Then I tried to be a good open source drone and add 20 /* fall through */
comments to libmpdec.
gcc is too stupid to recognize the /* fall through */ at the
Changes by Stefan Krah :
--
pull_requests: +3177
___
Python tracker
<http://bugs.python.org/issue30923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset d73a960c575207539c3f9765cff26d4fff400b45 by Stefan Krah in branch
'master':
bpo-30923: Disable warning that has been part of -Wextra since gcc-7.0. (#3142)
https://github.com/python/cpython/commit/d73a960c575207539c3f9765cff26d
Changes by Stefan Krah :
--
pull_requests: +3194
___
Python tracker
<http://bugs.python.org/issue30923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
PR 3157 addresses everything apart from expat and
https://github.com/python/cpython/blob/master/Modules/cjkcodecs/_codecs_iso2022.c#L816
I'm not sure about that one. It looks harmless but a bit odd.
--
___
P
Stefan Krah added the comment:
New changeset f432a3234f9f2ee09bd40be03e06bf72865ee375 by Stefan Krah in branch
'master':
bpo-30923: Silence fall-through warnings included in -Wextra since gcc-7.0.
(#3157)
https://github.com/python/cpython/commit/f432a3234f9f2ee09bd40be03e06bf
Stefan Krah added the comment:
Cherry picking has too many conflicts, I'm not backporting this myself.
--
___
Python tracker
<http://bugs.python.org/is
Stefan Krah added the comment:
pypy-5.8.0-beta0 (Python 3.5.3) is using a very nicely written CFFI wrapper for
libmpdec, so it also has the fast bignums.
--
___
Python tracker
<http://bugs.python.org/issue26
Stefan Krah added the comment:
What needs to be mentioned though is that the context has to be set
for unrounded calculations:
c = getcontext()
c.prec = MAX_PREC
c.Emax = MAX_EMAX
c.Emin = MIN_EMIN
Otherwise some people believe that the bignums are just rounded floating point
arithmetic that
Changes by Stefan Krah :
--
pull_requests: +3242
___
Python tracker
<http://bugs.python.org/issue30923>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset 9e1e6f528f3fec16b9bd99f5ee38048ffec04a81 by Stefan Krah in branch
'master':
bpo-30923: Silence fall-through warnings in libexpat build. (#3205)
https://github.com/python/cpython/commit/9e1e6f528f3fec16b9bd99f5ee3804
New submission from Stefan Krah:
The last fall-through warning is in _codecs_iso2022.c. IMO the
current code is equivalent to this, but I'm no codecs expert at
all:
diff --git a/Modules/cjkcodecs/_codecs_iso2022.c
b/Modules/cjkcodecs/_codecs_iso2022.c
index 1ce4218f30..abf214880f 100644
Stefan Krah added the comment:
All warnings except for #31275 are dealt with.
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
___
Python tracker
<http://bugs.python
Changes by Stefan Krah :
--
pull_requests: +3243
___
Python tracker
<http://bugs.python.org/issue31275>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset 138753c1b96b5e06a5c5d409fa4cae5e2fe1108b by Stefan Krah in branch
'master':
bpo-31275: Small refactoring to silence a fall-through warning. (#3206)
https://github.com/python/cpython/commit/138753c1b96b5e06a5c5d409fa4cae
Stefan Krah added the comment:
Thanks, Serhiy!
--
components: +Build
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
versions: +Python 3.7
___
Python tracker
<http://bugs.python
New submission from Stefan Krah:
gcc-7.2 emits the following not-so-useful warning:
Objects/bytearrayobject.c:226:9: warning: ‘memcpy’: specified size between
9223372036854775808 and 18446744073709551615 exceeds maximum object size
9223372036854775807
--
messages: 300851
nosy: skrah
Changes by Stefan Krah :
--
pull_requests: +3244
___
Python tracker
<http://bugs.python.org/issue31279>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset dce6502059f46a04f90938b9d832394c8215397b by Stefan Krah in branch
'master':
bpo-31279: Silence -Wstringop-overflow warning. (#3207)
https://github.com/python/cpython/commit/dce6502059f46a04f90938b9d83239
Changes by Stefan Krah :
--
components: +Build
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> compile error
versions: +Python 3.7
___
Python tracker
<http://bugs.python
Stefan Krah added the comment:
I'm very much in favor of using abort() /* NOT REACHED */ in such cases.
The only drawback is that in the case of libraries, sometimes
distribution package lint tools complain.
--
nosy: +skrah
___
Python tracker
Stefan Krah added the comment:
Regarding lint warnings, I may have confused abort() with exit().
Lintian has the shlib-calls-exit tag, somehow I thought there was
a similar one for abort(), but I can't find it now.
--
___
Python tracker
Stefan Krah added the comment:
> Is /* NOT REACHED */ a common convention?
I think it's often used in BSD, I first saw it in OpenBSD.
A macro is fine of course.
--
___
Python tracker
<http://bugs.python.org
Stefan Krah added the comment:
And Solaris lint recognizes it:
https://docs.oracle.com/cd/E60778_01/pdf/E60745.pdf
Actually it could be that the convention comes right from K&R, but I
can't find my copy right now.
--
___
Python track
Stefan Krah added the comment:
On Tue, Sep 05, 2017 at 05:10:24PM +, STINNER Victor wrote:
> That's a good example of better implementation for Py_UNREACHABLE().
>
> The tricky part is to make compiler warnings quiet. For example, you cannot
> replace "abort(); ret
Changes by Stefan Krah :
--
assignee: skrah
components: Extension Modules
nosy: skrah
priority: normal
severity: normal
status: open
title: Remove WITHOUT_THREADS from _decimal
type: behavior
versions: Python 3.7
___
Python tracker
<ht
Changes by Stefan Krah :
--
keywords: +patch
pull_requests: +3466
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31403>
___
___
Py
New submission from Stefan Krah:
New changeset c0c29dff7940b7e7ecc1dd051080c5d5f9e42ba8 by Stefan Krah in branch
'master':
bpo-31403: Remove WITHOUT_THREADS from _decimal. (#3474)
https://github.com/python/cpython/commit/c0c29dff7940b7e7ecc1dd051080c5
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Changes by Stefan Krah :
--
pull_requests: +3468
___
Python tracker
<https://bugs.python.org/issue31406>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Stefan Krah:
./configure --without-pymalloc produces:
Objects/obmalloc.c: In function ‘bumpserialno’:
Objects/obmalloc.c:1326:21: error: ‘struct _pymem_runtime_state’ has no member
named ‘serialno’
++_PyRuntime.mem.serialno;
^
Objects/obmalloc.c
New submission from Stefan Krah:
I traced this valgrind result down to
2ebc5ce42a8a9e047e790aefbf9a94811569b2b6 :
==23495== 240 (72 direct, 168 indirect) bytes in 1 blocks are definitely lost
in loss record 2,255 of 2,922
==23495==at 0x4C2A9A1: malloc (vg_replace_malloc.c:299)
==23495
Stefan Krah added the comment:
New changeset 3cedf46cdbeefc019f4a672c1104f3d5e94712bd by Stefan Krah in branch
'master':
bpo-31406: Fix crash due to lack of type checking in subclassing. (#3477)
https://github.com/python/cpython/commit/3cedf46cdbeefc019f4a672c1104f3
Stefan Krah added the comment:
New changeset f8909d0e4b652256e4da153fa6be664490f60a07 by Stefan Krah (Miss
Islington (bot)) in branch '3.6':
[3.6] bpo-31406: Fix crash due to lack of type checking in subclassing.
(GH-3477) (#3479)
https://github.com/python/cpyt
Stefan Krah added the comment:
Thanks for the report and the patch!
--
resolution: -> fixed
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org/issu
Changes by Stefan Krah :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue31406>
___
___
Pyth
Stefan Krah added the comment:
Could be the same as #31408.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue31420>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
It's fixed, thanks!
--
resolution: -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder: -> Reference leaks introduced by bpo-30860
___
Python tracker
<https://bugs.p
Stefan Krah added the comment:
Pythons has binary floating point, which does not give the same
results as a pocket calculator.
You can see the differences by using the decimal module:
# These are the binary floats in exact decimal representation.
>>> Decimal(7.95
Stefan Krah added the comment:
PyType_GenericNew() should be in libpython, so indeed the example in the docs
seems a bit odd to me.
--
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue31
Stefan Krah added the comment:
FWIW, I've been using
https://github.com/python/cpython/blob/master/Modules/_decimal/_decimal.c#L689
the static initialization on problematic platforms like Windows and
AIX for years, without any problems.
I'm sure this is valid C, and people
Stefan Krah added the comment:
Christian, do you remember which compiler was the reason for the commit
cbf3b5cb76906fba15dbf59a1e83c540a447b907 ?
+ /* Due to cross platform compiler issues the slots must be filled
+* here. It's required for portability to Windows wi
Stefan Krah added the comment:
Thanks, Christian. -- I found that in the docs the culprit is Cygwin:
db6a569de7ae595ada53b618fce6bbbd1c98d350
--
___
Python tracker
<https://bugs.python.org/issue31
Stefan Krah added the comment:
I've just asked on python-dev if Cygwin is still broken. Not sure
if we support it.
--
___
Python tracker
<https://bugs.python.org/is
Changes by Stefan Krah :
--
keywords: +patch
pull_requests: +3678
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31443>
___
___
Py
Stefan Krah added the comment:
Erik, if you are interested in Cygwin, could you please check that xxmodule.c
builds on Cygwin with the patch? You need to uncomment
a couple of lines in setup.py to build 'xx'.
--
___
Python track
Stefan Krah added the comment:
In fact, building _decimal should also fail on Cygwin if this
were still an issue.
--
___
Python tracker
<https://bugs.python.org/issue31
Stefan Krah added the comment:
Okay, thanks.
I found that bz2module.c has also used direct initialization for ages.
I'm going to commit the change.
--
___
Python tracker
<https://bugs.python.org/is
Stefan Krah added the comment:
New changeset ca72589bfabe2fd0e12eebfeb770b6c7a499b3e6 by Stefan Krah in branch
'master':
bpo-31443: Formulate the type slot initialization rules in terms of C99. (#3688)
https://github.com/python/cpython/commit/ca72589bfabe2fd0e12eebfeb770b6
Changes by Stefan Krah :
--
pull_requests: +3681
___
Python tracker
<https://bugs.python.org/issue31443>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Krah added the comment:
New changeset b1558a0368949714f5765702a8d83a2d163eaacf by Stefan Krah in branch
'master':
bpo-31443: Update included code. (#3697)
https://github.com/python/cpython/commit/b1558a0368949714f5765702a8d83a
Changes by Stefan Krah :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7
___
Python tracker
<https://bugs.python.or
Stefan Krah added the comment:
The suppressions are mainly for "invalid access" due to a gc trick.
The primary goal is to be definitely-lost-clean.
I would say it works as expected.
--
nosy: +skrah
___
Python tracker
<https://bu
Stefan Krah added the comment:
Also, I don't think --with-pydebug works well with valgrind.
It's either:
1) --with-pydebug
2) CFLAGS="-O0 -g" --with-valgrind
3) CFLAGS="-O0 -g" --without-pymalloc
Combining 2) and 3) probably does not hurt, but is not nec
Stefan Krah added the comment:
I'm using &PyTuple_GET_ITEM(args, 0), so Serhiy's concern is not theoretical.
I think if people want the safe version they should use PyTuple_GetItem().
--
nosy: +skrah
___
Python tracker
<https:
Stefan Krah added the comment:
Since this feature mainly helps when running a test suite using a debug build:
The same can be achieved by running the test suite under Valgrind, which
catches invalid accesses and a lot more.
So I'd prefer to keep the macro in its current
Stefan Krah added the comment:
If the feature is for the Python test suite itself, one solution would be to
add -DPY_BOUNDS_CHECKS and use that on the buildbots.
I still think making all of the test suite Valgrind-ready (most of it is,
except test_multiprocessing and a few others) would
Stefan Krah added the comment:
The feature would violate fundamental Python invariants. If you modify the
example above:
>>> t = (m,)
>>> b"\001\002\003" in t
True
>>> x[0] = 100
>>> b"\001\002\003" in t
False
This is simply never sup
Stefan Krah added the comment:
Sorry I meant the above example to use a dict, which currently
does not work:
>>> d = {m: "1"}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'numpy.ndarray'
Then the fea
Stefan Krah added the comment:
I'll leave the issue up for a couple of days in case someone supports it, but I
think this one of the rare cases where all core devs would reject the feature
unanimously.
--
resolution: -> not a bug
status: open -> pending
type: -&g
Stefan Krah added the comment:
The reason is that unfortunately readonly != immutable, as the
following example shows:
>>> import numpy as np
>>> x = np.array([1,2,3], dtype='B')
>>> y = x[:]
>>> y.flags['WRITEABLE'] = False
>>&
Stefan Krah added the comment:
"--with-valgrind --with-pydebug" looks suspicious, it essentially
mixes two different memory checkers.
1) CFLAGS="-O0 -g" --without-pymalloc
2) CFLAGS="-O0 -g" --with-valgrind
should both work.
Can you try if this fixes the e
Stefan Krah added the comment:
memoryview.cast() was originally meant to be a faster version of tobytes(),
which always converts to C-contiguous.
The 'shape' keyword was added because it is odd if you can cast from ND-C to
1D-Bytes but not back.
I'm not sure if we should
Stefan Krah added the comment:
I think there's another open GitHub issue for this, and yes, probably
it should be discussed on python-ideas, too.
My main concern with 'm' for libmpdec is that I'd like to reserve it
for LC_MONETARY. There was one OS X issue that would
Stefan Krah added the comment:
For reference, the (one of the?) other GitHub issue(s) is here:
https://github.com/python/cpython/pull/8612
It actually proposes to use LC_MONETARY.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
We use "crash" for segmentation fault, but this appears to be a regular
traceback that includes BufferError.
The BufferError message appears to be from mmapmodule.c.
--
title: memoryview contextmanager causing strange crash -> Buf
Stefan Krah added the comment:
The behavior seems to be correct to me: If there are exports, the memoryview
cannot be released.
The application needs to ensure that release() is not called when
there are exports left.
--
___
Python tracker
Stefan Krah added the comment:
Well, the problem in b) is that data[:2] creates a new memoryview,
so the underlying ManagedBufferObject now has two exports:
- One from the context manager.
- The second from the slice.
So memoryview.__exit__() decrements on export, but the second one
is
Stefan Krah added the comment:
s/on export/one export/
--
___
Python tracker
<https://bugs.python.org/issue35686>
___
___
Python-bugs-list mailing list
Unsub
Stefan Krah added the comment:
Or, obviously:
with open(fn, 'rb') as fd:
with mmap.mmap(fd.fileno(), 0, access=mmap.ACCESS_READ) as mm:
with memoryview(mm)[:2] as data:
print(data)
--
___
Python track
Stefan Krah added the comment:
> Since it seems like we are still at the "idea" stage, would it make sense to
> add a function which accept options to choose how to format a number?
Maybe, but I think for format() Eric's latest proposal on python-ideas is great
(&qu
Change by Stefan Krah :
--
assignee: -> skrah
nosy: +skrah
___
Python tracker
<https://bugs.python.org/issue35697>
___
___
Python-bugs-list mailing list
Un
Stefan Krah added the comment:
Since #7442 (again, *I* discovered this and it is *mentioned* in the
_decimal sources), there have been zero bug reports about decimal.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
Don't you find it strange to close #7442 in mutual agreement and now
mention the word "bug" 50 times?
--
___
Python tracker
<https://bugs.pyt
Change by Stefan Krah :
--
title: decimal: formatter error if LC_NUMERIC uses a different encoding than
LC_CTYPE -> _decimal: Implement the previously rejected changes from #7442.
___
Python tracker
<https://bugs.python.org/issu
Stefan Krah added the comment:
Also Marc-Andre does not consider this a bug in #31900. The
presentation of this issue is increasingly bizarre.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
I mean issue reports like #33954 or #35195. These are just
two examples, and I'm NOT claiming that they are related.
But if functions like _PyUnicode_InsertThousandsGrouping()
*were* used in _decimal, I'd feel compelled to investigate.
Now I don'
Stefan Krah added the comment:
This is a performance sensitive function, so I prefer not to add
volatile. MSVC also had a bug with that function, but only in PGO
mode. Microsoft has fixed the issue long ago.
Do newer gcc versions have this issue?
I'm fine with wrapping the entire macro
Stefan Krah added the comment:
Does it also work with -fno-inline, just for ppc64? There are other
places in the sources where an inlined memcpy() could be miscompiled.
--
___
Python tracker
<https://bugs.python.org/issue35
Stefan Krah added the comment:
If gcc-8.0.1-0.14.fc28.ppc64le miscompiles memcpy(), perhaps the upstream
priority in https://bugzilla.redhat.com/show_bug.cgi?id=1540995 should be
"release blocker".
CC David Edelsohn, whose PPC64 buildbot (presumably big endian) works.
-
Stefan Krah added the comment:
Okay, so it's not a severe bug. That leaves us with the question
what to do about it. As I said above, other call sites could be
affected, too:
_struct.c:
static int
np_float(char *p, PyObject *v, const formatdef *f)
{
float x = (float)PyFloat_AsDou
Stefan Krah added the comment:
Our mails apparently crossed. :-)
--
___
Python tracker
<https://bugs.python.org/issue35752>
___
___
Python-bugs-list mailin
Stefan Krah added the comment:
Or to put it differently, should we put a specific fix for a single
gcc version into memoryview.c? For all we know, a fix will be pushed
to Fedora 28 in the next 4 months.
--
___
Python tracker
<ht
Stefan Krah added the comment:
> For me, the main risk is to forget to remove the workaround once a new GCC
> version will be released (in N months).
This is why I suggested using the reproducer in configure.ac, setting something
like HAVE_GCC_MEMCPY_ROUNDING_BUG and then either a) wr
Change by Stefan Krah :
--
assignee: -> skrah
___
Python tracker
<https://bugs.python.org/issue35752>
___
___
Python-bugs-list mailing list
Unsubscrib
Stefan Krah added the comment:
Yes, it's modeled after NumPy's tobytes():
>>> x = np.array(list(range(6)), dtype="int8").reshape(2,3)
>>> x.tobytes()
b'\x00\x01\x02\x03\x04\x05'
>>> x.T.tobytes()
b'\x00\x03\x01\x04\x02\x05
1101 - 1200 of 3396 matches
Mail list logo
