#3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171' --------------------------+--------------------------------- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.2.2 Component: Python | Version: svn-releasebranch72 Resolution: | Keywords: ctypes, python CPU: Unspecified | Platform: Unspecified --------------------------+---------------------------------
Comment (by glynn): Replying to [comment:7 neteler]: > Adding some debug output shows where in the lexer the problem occurs: > {{{ [root@f1e5cbaaed18 ctypes]# make | grep 084202 #define __LDBL_EPSILON__ 1.08420217248550443400745280086994171e-19L #define __FLT64X_EPSILON__ 1.08420217248550443400745280086994171e-19F64x g1 = str(long(g1, 8)) ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171' }}} > As seen above the `__LDBL_EPSILON__` definition is not parsed properly It's more likely to be an issue with `__FLT64X_EPSILON__`, as that's a recent addition. `__LDBL_EPSILON__` has been defined since forever, and hasn't caused problems before. Looking through pplexer.py shows that it specifically tries to handle literals with an "L" or "l" suffix, but there's nothing there for an "F64x" suffix. So the value won't match the regex for a float literal, which probably results in it matching "1." as a float literal then trying to match the remainder. The part up to the exponent will match an int literal, but the leading zero causes it to be parsed as octal, which then fails due to the presence of digits 8 and 9. You can dump out gcc's built-in macro definitions with {{{ gcc -E -dM -x c /dev/null | sort }}} Does adding e.g. -std=c89 or -std=c99 eliminate the F64x literals? FWIW, F64x appears to derive from ISO/IEC TS 18661-3:2015. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/3331#comment:17> GRASS GIS <https://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev