On Mar 20, 2016, at 09:07, Michael Felt <mich...@felt.demon.nl> 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 a compiler could easily allow an
>> implementation-defined type that's identical to and interconvertible with
>> short, say "i16", to be used in bitfields, but not short itself.
>>
>> And yet, gcc still allows short "even in strictly conforming mode" (4.9),
>> and it looks like Clang and Intel do the same.
>>
>> Meanwhile, MSVC specifically says it's illegal ("The type-specifier for the
>> declarator must be unsigned int, signed int, or int") but then defines the
>> semantics (you can't have a 17-bit short, bit fields act as the underlying
>> type when accessed, alignment is forced to a boundary appropriate for the
>> underlying type). They do mention that allowing char and long types is a
>> Microsoft extension, but still nothing about short, even though it's used in
>> most of the examples on the page.
>>
>> Anyway, is the question what ctypes should do? If a platform's compiler
>> allows "short M: 1", especially if it has potentially different alignment
>> than "int M: 1", ctypes on that platform had better make ("M", c_short, 1)
>> match the former, right?
>>
>> So it sounds like you need some configure switch to test that your compiler
>> doesn't allow short bit fields, so your ctypes build at least skips that
>> part of _ctypes_test.c and test_bitfields.py, and maybe even doesn't allow
>> them in Python code.
>>
>>
>>>> >> test_short fails om AIX when using xlC in any case. How terrible is
>>>> >> this?
> a) this does not look solveable using xlC, and I expect from the comment
> above re: MSVC, that it will, or should also fail there.
> And, imho, if anything is to done, it is a decision to be made by "Python".
Sure, but isn't that exactly why you're posting to this list?
> b) aka - it sounds like a defect, at least in the test.
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.
So it sounds like you need a flag coming from autoconf that can be tested in C
(and probably in Python as well) that tells you whether the compiler can handle
it. And I don't think there is any such flag.
Which means someone would have to add the configure test. And if people who use
MSVC, gcc, and clang are all unaffected, I'm guessing that someone would have
to be someone who cares about xlC or some other compiler, like you.
The alternative would be to just change the docs to make it explicit that using
non-int bitfields isn't supported but may work in platform-specific ways. If
you got everyone to agree to that, surely you could just remove the tests,
right? But if people are actually writing C code that follows the examples on
the MSVC bitfield docs page, and need to talk to that code from ctypes, I don't
know if it would be acceptable to stop officially supporting that.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
