Michael Felt added the comment:
Using:
root@x064:[/data/prj/aixtools/python/tests]cat -n bits.c
1 struct BITS {
2 signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9;
3 signed short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7;
4 signed char T: 1, U: 2, V: 3;
5 unsigned char W: 1, X: 2, Y: 3;
6 signed long J: 1, K: 2, L: 3;
7 };
Using:
root@x064:[/data/prj/aixtools/python/tests]xlc -qversion
IBM XL C/C++ for AIX, V11.1 (5724-X13)
Version: 11.01.0000.0020
I get:
root@x064:[/data/prj/aixtools/python/tests]xlc -c bits.c
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for M is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for N is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for O is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for P is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for Q is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for R is not
valid. Type unsigned assumed.
"bits.c", line 3.5: 1506-159 (E) Bit field type specified for S is not
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for T is not
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for U is not
valid. Type unsigned assumed.
"bits.c", line 4.5: 1506-159 (E) Bit field type specified for V is not
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for W is not
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for X is not
valid. Type unsigned assumed.
"bits.c", line 5.5: 1506-159 (E) Bit field type specified for Y is not
valid. Type unsigned assumed.
On 23-Aug-16 01:06, Martin Panter wrote:
> Martin Panter added the comment:
>
> Now I am confused. In <https://bugs.python.org/issue27643#msg271773> we have
>
> [Me] If your compiler does not support “signed short” bitfields, maybe we
> just have to accept that ctypes supports it even though the compiler doesn’t,
> and skip the test.
As the test also fails for A..I when not specified as signed int, if you
have not already "changed" that (I forget in the time passed), then that
should, at least be specified for the A..I BITS definition.
I do not understand what you mean by "supports" - yes, it can be
assigned, but the result you get when "querying" the bit depends on how
you query it. Is that "support" when conflicting values are returned?
Don't mind my not understanding - If skipping "solves" it, then yes,
skip the test.
>
> [Michael] Looks like this may be the approach: as signed int, signed short
> give the same message - it seems that xlc (and maybe Sun C) does not accept
> "short" as a bitfield type.
>
> Apparently XLC doesn’t accept signed short bitfields for Michael, but does
> for Eric. What’s going on? Maybe different versions?
>
> ----------
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue27643>
> _______________________________________
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27643>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
