On 2016-03-18 00:56, Michael Felt wrote: > Update: > Is this going to be impossible? > From what I've been able to find out, the C89 standard limits bitfields to int, signed int and unsigned int, and the C99 standard added _Bool, although some compilers allow other integer types too. It looks like your compiler doesn't allow those additional types. > test_short fails om AIX when using xlC in any case. How terrible is this? > > ====================================================================== > FAIL: test_shorts (ctypes.test.test_bitfields.C_Test) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/data/prj/aixtools/python/python-2.7.11.2/Lib/ctypes/test/test_bitfields.py", > line 48, in test_shorts > self.assertEqual((name, i, getattr(b, name)), (name, i, > func(byref(b), name))) > AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1) > > First differing element 2: > -1 > 1 > > - ('M', 1, -1) > ? - > > + ('M', 1, 1) > > ---------------------------------------------------------------------- > Ran 440 tests in 1.538s > > FAILED (failures=1, skipped=91) > Traceback (most recent call last): > File "./Lib/test/test_ctypes.py", line 15, in <module> > test_main() > File "./Lib/test/test_ctypes.py", line 12, in test_main > run_unittest(unittest.TestSuite(suites)) > File > "/data/prj/aixtools/python/python-2.7.11.2/Lib/test/test_support.py", > line 1428, in run_unittest > _run_suite(suite) > File > "/data/prj/aixtools/python/python-2.7.11.2/Lib/test/test_support.py", > line 1411, in _run_suite > raise TestFailed(err) > test.test_support.TestFailed: Traceback (most recent call last): > File > "/data/prj/aixtools/python/python-2.7.11.2/Lib/ctypes/test/test_bitfields.py", > line 48, in test_shorts > self.assertEqual((name, i, getattr(b, name)), (name, i, > func(byref(b), name))) > AssertionError: Tuples differ: ('M', 1, -1) != ('M', 1, 1) > > First differing element 2: > -1 > 1 > > - ('M', 1, -1) > ? - > > + ('M', 1, 1) > > > > > On 17-Mar-16 23:31, Michael Felt wrote: >> a) hope this is not something you expect to be on -list, if so - my >> apologies! >> >> Getting this message (here using c99 as compiler name, but same issue >> with xlc as compiler name) >> c99 -qarch=pwr4 -qbitfields=signed -DNDEBUG -O -I. -IInclude >> -I./Include -I/data/prj/aixtools/python/python-2.7.11.2/Include >> -I/data/prj/aixtools/python/python-2.7.11.2 -c >> /data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c >> -o >> build/temp.aix-5.3-2.7/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.o >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field M must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field N must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field O must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field P must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field Q must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field R must be of type signed int, >> unsigned int or int. >> "/data/prj/aixtools/python/python-2.7.11.2/Modules/_ctypes/_ctypes_test.c", >> line 387.5: 1506-009 (S) Bit field S must be of type signed int, >> unsigned int or int. >> >> for: >> >> struct BITS { >> int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9; >> short M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7; >> }; >> >> in short xlC v11 does not like short (xlC v7 might have accepted it, >> but "32-bit machines were common then". I am guessing that 16-bit is >> not well liked on 64-bit hw now. >> >> reference for xlC v7, where short was (apparently) still accepted: >> http://www.serc.iisc.ernet.in/facilities/ComputingFacilities/systems/cluster/vac-7.0/html/language/ref/clrc03defbitf.htm >> >> >> I am taking this is from xlC v7 documentation from the URL, not >> because I know it personally. >> >> So - my question: if "short" is unacceptable for POWER, or maybe only >> xlC (not tried with gcc) - how terrible is this, and is it possible to >> adjust the test so - the test is accurate? >> >> I am going to modify the test code so it is >> struct BITS { >> signed int A: 1, B:2, C:3, D:4, E: 5, F: 6, G: 7, H: 8, I: 9; >> unsigned int M: 1, N: 2, O: 3, P: 4, Q: 5, R: 6, S: 7; >> }; >> >> And see what happens - BUT - what does this have for impact on python >> - assuming that "short" bitfields are not supported? >> >> p.s. not submitting this a bug (now) as it may just be that "you" >> consider it a bug in xlC to not support (signed) short bit fields. >> >> p.p.s. Note: xlc, by default, considers bitfields to be unsigned. I >> was trying to force them to signed with -qbitfields=signed - and I >> still got messages. So, going back to defaults. >>
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