[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 967b06d56a69 by Stefan Krah in branch 'default': Issue #14779: Get sizeof(void *) directly rather than relying on sysconfig. http://hg.python.org/cpython/rev/967b06d56a69 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 8f22e5be18c8 by Stefan Krah in branch 'default':
Issue #14779: Do not use get_config_var('SIZEOF_VOID_P') on OS X 64-/32-bit
http://hg.python.org/cpython/rev/8f22e5be18c8
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14779
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Stefan Krah stefan-use...@bytereef.org added the comment: Apparently the AS/400 had 128 bit pointers and IBM's System i still has them: http://comments.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/651 http://www-01.ibm.com/support/docview.wss?uid=swg27019425 So I'll leave the SIZEOF_VOID_P test as the preferred method. Perhaps the best way to sidestep all these issues would be to write a small C module for getting type sizes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Stefan Krah stefan-use...@bytereef.org added the comment:
The sysconfig docs say: configuration variables relevant for the
current platform
If get_config_var('SIZEOF_VOID_P') is meaningless for universal builds,
then IMO it should return None. None would then mean either not found
or irrelevant.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14779
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Antoine Pitrou pit...@free.fr added the comment: Well, no need to ever use SIZEOF_VOID_P. sys.maxsize should always tell you whether the build is 32-bit or 64-bit. -- nosy: +mark.dickinson, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
Stefan Krah stefan-use...@bytereef.org added the comment: The tests for arrays with suboffsets literally need sizeof(void *). I don't think C guarantees SIZEOF_VOID_P == SIZEOF_SIZE_T. If HAVE_SSIZE_T is defined in pyport.h, AFAICS no such check is made. Of course these concerns may be entirely theoretical. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14779] test_buffer fails on OS X universal 64-/32-bit builds
New submission from Ned Deily n...@acm.org: test_buffer can fail when run on an OS X 64-/32-bit universal build of Python is run in 32-bit mode. $ /usr/local/bin/python3.3 -m test test_buffer [1/1] test_buffer 1 test OK. $ /usr/local/bin/python3.3-32 -m test -v test_buffer == CPython 3.3.0a3 (v3.3.0a3:0b53b70a40a0, May 1 2012, 11:39:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] == Darwin-11.4.0-x86_64-i386-64bit little-endian == /private/var/folders/fm/9wjgctqx61n796zt88qmmnxcgn/T/test_python_56263 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_buffer [...] test_memoryview_construction (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_format_shape (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_format_strides (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_getbuf (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_multidim (test.test_buffer.TestBufferProtocol) ... FAIL test_ndarray_slice_assign_single (test.test_buffer.TestBufferProtocol) ... FAIL [...] The test is incorrectly testing a compile-time configuration variable which is not meaningful for universal builds since each architecture can have different values. Further, the platform.architecture fallback test is also unreliable; as noted in the docs for the platform module, sys.maxsize should be used for run-time tests. The attached patch fixes the test for OS X. -- files: issueX_test_buffer.patch keywords: patch messages: 160382 nosy: ned.deily, skrah priority: normal severity: normal stage: patch review status: open title: test_buffer fails on OS X universal 64-/32-bit builds versions: Python 3.3 Added file: http://bugs.python.org/file25532/issueX_test_buffer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
