Michael Felt added the comment:
On 23-Aug-16 21:23, Michael Felt wrote:
> 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.
p.s. I guess we can assume, better infer, this message does not mean
"unsigned whatever" but unsigned (unspoken int)
> "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 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
