On 4/4/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
I assume you meant "shouldn't be any negative consequences" there ;) I thought this over during dinner (mmmm, curry) and I agree that we shouldn't make PY_SSIZE_T_CLEAN change output variables that the compiler can catch. Too much effort, and in the end it'll just cause extensions compiled for 64-bit python to not use 64-bit values 'silently' (although eventually something'll get truncated and people will get confused.) This at least gives a compile-time hint that, on 64-bit platforms, things aren't quite right.
It's just too bad that it's an easily overlooked hint, and that you can't get that hint when compiling for 32-bit platforms. Extension writers with 64-bit hardware access and the desire to compile, let alone test, on said hardware is still rare. If we did make PY_SSIZE_T_CLEAN adjust all Py_ssize_t*-using functions (which would mean a *lot* of API duplication), we could add a #warning for every use of the old API calls, so everyone sees it, even on 32-bit platforms. The warning should contain a pointer to a document describing how to conveniently support both Python 2.5+ and 2.4-, though. Too much work for alpha1, in any case, and probably too much work period. The webpage should be made, though, if just to refer to in the release notes.
Thomas Wouters wrote:
> And so I could. test_banana.CananaTestCase.testCrashNegativeLong
> crashes, because it calls PyString_AsStringAndSize() with an int-ptr as
> second argument (an adjacent ptr variable becomes garbage.) That's
> certainly a problem with the Py_ssize_t change. Martin, aren't all
> output variables (or ptr-variables, rather) supposed to be controlled by
> the 'PY_SSIZE_T_CLEAN' #define? People aren't going to notice their
> compiler warnings; I know I didn't :)
No: this is the discussion I had with MAL. You have to watch for
compiler warnings talking about incorrect pointer types. These
days, you can apply Fredrik's checker to find out that you are
using functions that output Py_ssize_t.
Ignoring the warning might cause crashes on 64-bit machines. On
32-bit machines, there should be any negative consequence.
I assume you meant "shouldn't be any negative consequences" there ;) I thought this over during dinner (mmmm, curry) and I agree that we shouldn't make PY_SSIZE_T_CLEAN change output variables that the compiler can catch. Too much effort, and in the end it'll just cause extensions compiled for 64-bit python to not use 64-bit values 'silently' (although eventually something'll get truncated and people will get confused.) This at least gives a compile-time hint that, on 64-bit platforms, things aren't quite right.
It's just too bad that it's an easily overlooked hint, and that you can't get that hint when compiling for 32-bit platforms. Extension writers with 64-bit hardware access and the desire to compile, let alone test, on said hardware is still rare. If we did make PY_SSIZE_T_CLEAN adjust all Py_ssize_t*-using functions (which would mean a *lot* of API duplication), we could add a #warning for every use of the old API calls, so everyone sees it, even on 32-bit platforms. The warning should contain a pointer to a document describing how to conveniently support both Python 2.5+ and 2.4-, though. Too much work for alpha1, in any case, and probably too much work period. The webpage should be made, though, if just to refer to in the release notes.
--
Thomas Wouters < [EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
