This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Michael.Felt
Recipients David.Edelsohn, Michael.Felt, aixtools@gmail.com, ericvw, martin.panter
Date 2018-01-11.19:19:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <e534fac6-16b4-66f3-d0c3-f8cde1f57ff6@felt.demon.nl>
In-reply-to <1469839915.17.0.167633993095.issue27643@psf.upfronthosting.co.za>
Content
On 30/07/2016 02:51, Martin Panter wrote:
> Martin Panter added the comment:
>
>
> ./python -m unittest -v ctypes.test.test_bitfields
>
> What I am suggesting as a fix is to change line 381 from plain “int” to “signed int”, and 382 to “signed short”.

As some time has passed, I assume you mean look at this change:

struct BITS {
     signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
     signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
};

> I can make a patch later if that will help. Hopefully with these changes the C compiler will use signed integer logic, matching what I believe the ctypes library uses for c_int and c_short.

Not helping the compilation in any case - same messages as before.

* Default make:

michael@x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r -DNDEBUG -O 
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -I/opt/>
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type unsigned assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type unsigned assumed.

* Adding (manually) -qbitfields=signed - almost the same.

michael@x071:[/data/prj/python/git/xlc-python3-3.7]xlc_r 
-qbitfields=signed -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 >
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for M is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for N is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for O is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for P is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for Q is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for R is not valid. 
Type signed assumed.
"/data/prj/python/git/xlc-python3-3.7/Modules/_ctypes/_ctypes_test.c", 
line 418.5: 1506-159 (E) Bit field type specified for S is not valid. 
Type signed assumed.

> Using a type other than short is not right, because the Python test is explicitly trying to test c_short behaviour. If your compiler does not support “signed short” bitfields, maybe we just have to accept that ctypes supports it even though the compiler doesn’t, and skip the test.
Shall reply, asap, to your suggestion for a test that knows the 
difference in compilers.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27643>
> _______________________________________
History
Date User Action Args
2018-01-11 19:19:55Michael.Feltsetrecipients: + Michael.Felt, ericvw, martin.panter, David.Edelsohn
2018-01-11 19:19:55Michael.Feltlinkissue27643 messages
2018-01-11 19:19:55Michael.Feltcreate