On the implicit cast - the 1 sentence synopsis: Should be fine for
CPython >= 2.5, otherwise I'm dubious.


The details:

I did a google search on Py_ssize_t [1], and the first two hits are relevant:

>From PEP 353 [2]: "A new type Py_ssize_t is introduced, which has the
same size as the compiler's size_t type, but is signed. It will be a
typedef for ssize_t where available."  Because there's an assertion in
the wrapper code that the size is non-negative, a cast to size_t will
never alter the semantic value, *when* that definition is used.

However, the second hit [3] discusses the proper way to write
extension modules that are backwards compatible with CPython 2.5, and
I though I didn't follow it thoroughly, I have the impression that on
pre-2.5, there could be problems here and elsewhere.  Does Tahoe-LAFS
intend to support pre-2.5 CPython?

[1] http://www.google.com/search?q=py_ssize_t
[2] http://www.python.org/dev/peps/pep-0353/
[3] http://bugs.python.org/issue1485576



On Tue, Sep 8, 2009 at 11:39 PM, pycryptopp <[email protected]> wrote:
> #19: Segmentation fault in HashMultipleBlocks
> ---------------------+------------------------------------------------------
> Reporter:  francois  |           Owner:  francois
>    Type:  defect    |          Status:  new
> Priority:  major     |         Version:  0.5.1
> Keywords:            |   Launchpad_bug:
> ---------------------+------------------------------------------------------
>
> Comment(by warner):
>
>  Nice catch! I just pushed [669] with your fix: set PY_SSIZE_T_CLEAN
>  everywhere, and update the two remaining uses of "int"-sized {{{t#}}}
>  length variables to be Py_ssize_t instead. The segfaults go away, and
>  tests pass on linux/32bit, OS-X/10.6/64bit, OS-X/10.5/probably-64-bit.
>
>  I didn't touch that implicit cast. If your analysis points out a problem,
>  give a yell.
>
>  francois: could you play with this patch and see if it makes your segfault
>  go away? I know that it happens infrequently enough that it'll be hard to
>  develop confidence by merely running the test suite a few times, but maybe
>  if you observed no crash for three times as long as the usual time it
>  takes to crash, we could treat this one as done..
>
> --
> Ticket URL: <http://allmydata.org/trac/pycryptopp/ticket/19#comment:6>
> pycryptopp <http://allmydata.org/trac/pycryptopp>
> Python bindings for the Crypto++ library
> _______________________________________________
> tahoe-dev mailing list
> [email protected]
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
_______________________________________________
tahoe-dev mailing list
[email protected]
http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev

Reply via email to