Andy Lester added the comment:
Casting tail to (void *)tail was the correct thing to do. The problem is that
casting to void* casts away the constness of tail. The even more correct thing
to do is what my patch does, which is cast it to (const void *)tail.
There is no functional
Change by Andy Lester :
--
pull_requests: +18572
pull_request: https://github.com/python/cpython/pull/19209
___
Python tracker
<https://bugs.python.org/issue39
Change by Andy Lester :
--
pull_requests: +18573
pull_request: https://github.com/python/cpython/pull/19210
___
Python tracker
<https://bugs.python.org/issue39
Change by Andy Lester :
--
pull_requests: +18692
pull_request: https://github.com/python/cpython/pull/19327
___
Python tracker
<https://bugs.python.org/issue39
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40170>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andy Lester :
--
pull_requests: +18766
pull_request: https://github.com/python/cpython/pull/19405
___
Python tracker
<https://bugs.python.org/issue39
Change by Andy Lester :
--
pull_requests: +18800
pull_request: https://github.com/python/cpython/pull/19445
___
Python tracker
<https://bugs.python.org/issue39
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40245>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andy Lester added the comment:
I remember coming across a similar error from GCC about casting from a const
double pointer to a single pointer void and it said (I believe) something about
having to have each cast having to be valid. I think it was implying something
like that if you have
Andy Lester added the comment:
I'm assuming that you're getting this sre_lib.h error when compiling
Modules/_sre.c.
--
___
Python tracker
<https://bugs.python.o
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40314>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40455>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andy Lester added the comment:
Did you add any options to the ./configure call for cpython? What were they?
--
___
Python tracker
<https://bugs.python.org/issue40
Andy Lester added the comment:
For anyone following along, note that the PR above is different than the
original suggestion. The PR correctly sets x_size, not leaving it zero.
--
___
Python tracker
<https://bugs.python.org/issue40
Change by Andy Lester :
--
nosy: -petdance
___
Python tracker
<https://bugs.python.org/issue39573>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andy Lester added the comment:
I'd also like to suggest that the question not be "most efficient" but
"fastest". I don't think it should treat "efficient" and "fast" as synonyms.
"Efficient" can mean things other than execution
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40770>
___
___
Python-bugs-list mailing list
Unsubscribe:
Andy Lester added the comment:
Some high-level questions to consider:
* Is it run only when a build of the docs is started? Or should it be done
regularly (daily/weekly?) to keep an eye on links so that it's not a surprise
when build time comes along?
* Does a broken link stop the
Change by Andy Lester :
--
nosy: +petdance
___
Python tracker
<https://bugs.python.org/issue40902>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Andy Lester :
--
nosy: -petdance
___
Python tracker
<https://bugs.python.org/issue40170>
___
___
Python-bugs-list mailing list
Unsubscribe:
101 - 121 of 121 matches
Mail list logo