[GRASS-dev] [GRASS GIS] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

[GRASS GIS]

#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 at 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>