Closed
Description
BPO | 24290 |
---|---|
Nosy | @ronaldoussoren, @ned-deily |
Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2015-05-26.19:02:48.705>
labels = ['ctypes', 'type-bug']
title = 'c_uint32 bitfields break structures'
updated_at = <Date 2015-05-27.22:57:25.193>
user = 'https://bugs.python.org/RonyBatista'
bugs.python.org fields:
activity = <Date 2015-05-27.22:57:25.193>
actor = 'Rony Batista'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['ctypes']
creation = <Date 2015-05-26.19:02:48.705>
creator = 'Rony Batista'
dependencies = []
files = ['39508']
hgrepos = []
issue_num = 24290
keywords = []
message_count = 5.0
messages = ['244125', '244126', '244127', '244132', '244223']
nosy_count = 3.0
nosy_names = ['ronaldoussoren', 'ned.deily', 'Rony Batista']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24290'
versions = ['Python 2.7']
Activity
RonyBatista commentedon May 26, 2015
ctypes Structures with c_uint32 bitfields have strange behaviour on OS X.
In the attached code when the field "number" is set, it changes the whole 32 bits, even thou its meant to be 23 bits.
The behavior is unexpected in:
OS X: Python 2.7.9
The behavior is as expected in the following environments:
Windows: python 2.7.9
Ubuntu: python 2.7.6
ronaldoussoren commentedon May 26, 2015
You forgot to actually attach the code.
RonyBatista commentedon May 26, 2015
Silly me, Heres the code.
ned-deily commentedon May 26, 2015
Without diving into the details of your test program, I get the same results on a 64-bit Debian Python 2.7.9 as with a 64-bit OS X 2.7.10:
c_uint32 TESTS:
Class Name exponent number Sign float binary repr
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a'])
AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb', '0xeb', '0x2a'])
AN575Float_uint ('0x0', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x0', '0xb', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 1.094551427887186e-39, ['0x85', '0xb', '0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 1L, 1.094551427887186e-39, ['0x85', '0x8b', '0xeb', '0x2a'])
But using the same OS X 2.7.10 in 32-bit mode, I get:
c_uint32 TESTS:
Class Name exponent number Sign float binary repr
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 0L, 69.95930480957031, ['0x42', '0x8b', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 0L, 69.95930480957031, ['0x85', '0xb', '0xeb', '0x2a'])
IEEE754Float_u ('-0x7b', '0xbeb2aL', 1L, -69.95930480957031, ['0xc2', '0x8b', '0xeb', '0x2a'])
AN575Float_uint ('-0x7b', '0xbeb2a', 1L, -69.95930480957031, ['0x85', '0x8b', '0xeb', '0x2a'])
RonyBatista commentedon May 27, 2015
Well, looks like the issue is with 64 bit mode then.
For the first 5 cases the right answer is 69.95930480957031, and for the last 2 its -69.95930480957031. The results for the 32 bit mode are all correct.
encukou commentedon May 13, 2025
Should be fixed in #97702.
Code updated for Python 3:
Result (same on 64- and 32-bit OS):