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?
_______________________________________________
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
