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".
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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4