[Python-Dev] bitfields - short - and xlc compiler (original) (raw)

Michael Felt michael at felt.demon.nl
Sun Mar 20 12:07:32 EDT 2016

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", cshort, 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 ctypestest.c and testbitfields.py, and maybe even doesn't allow them in Python code.

>> testshort 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". b) aka - it sounds like a defect, at least in the test. c) what danger is there to existing Python code if "short" is expected, per legacy when compilers did (and GCC still does - verified that when I compile with gcc the test does not signal failure)

So, more with regard to c) - is there something I could/should be looking at in Python itself, in order to message that the code is not supported by the compiler?

More information about the Python-Dev mailing list