On 3/20/2016 4:04 PM, Andrew Barnert via Python-Dev wrote:
Agreed. But I think the test is reasonable on at least MSVC, gcc, clang, and
icc. So what you need is some way to run the test on those compilers, but not
on compilers that can't handle it.
The test could be conditioned on the compil
On Mar 20, 2016, at 09:07, Michael Felt wrote:
>
>> On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote:
>> Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool,
>> signed int, unsigned int, or some other implementation-defined type", and
>> same for C11. This means that
On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote:
Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool, signed int, unsigned
int, or some other implementation-defined type", and same for C11. This means that a compiler
could easily allow an implementation-defined ty
On Mar 17, 2016, at 18:35, MRAB wrote:
>
>> On 2016-03-18 00:56, Michael Felt wrote:
>> Update:
>> Is this going to be impossible?
> From what I've been able to find out, the C89 standard limits bitfields to
> int, signed int and unsigned int, and the C99 standard added _Bool, although
> some c
Update:
Is this going to be impossible?
test_short fails om AIX when using xlC in any case. How terrible is this?
==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
-
On 2016-03-18 00:56, Michael Felt wrote:
Update:
Is this going to be impossible?
From what I've been able to find out, the C89 standard limits bitfields
to int, signed int and unsigned int, and the C99 standard added _Bool,
although some compilers allow other integer types too. It looks like