[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:17 glynn]:

 Incidentally, it doesn't correctly parse the decimal floating-point
 (dec32/64/128) literals produced by earlier versions of gcc (DF, DD, DL
 suffixes) either. Again, it ends up treating them as a sequence of
 integer/float/identifier tokens. But as these only occur in the
 definitions of macros which are never used, it doesn't actually matter.

 Essentially, it's just bad luck that the value of FLT64X_EPSILON happens
 to have a zero immediately after the decimal point, resulting in an
 attempt to parse as octal.

 There seem to be a couple of options for avoiding this. The regex for
 integer literals is (pplexer.py:243):
 {{{
 INT_LITERAL = sub(r"(?P<p1>(?:0x{H}+)|(?:{D}+))(?P<suf>{IS})")
 }}}
 where sub() performs the substitutions found at pplexer.py:50:
 {{{
 subs = {
     'D': '[0-9]',
     'L': '[a-zA-Z_]',
     'H': '[a-fA-F0-9]',
     'E': '[Ee][+-]?\s*{D}+',
     'FS': '[FflL]',
     'IS': '[uUlL]*',
 }
 }}}
 Changing this to
 {{{
 INT_LITERAL =
 sub(r"(?P<p1>(?:0x{H}+)|(?:0[0-7]+)|(?:[1-9]{D}+))(?P<suf>{IS})")
 }}}
 and deleting lextab.{py,pyc} (which will be regenerated) seems to avoid
 the issue. Such literals are still parsed incorrectly, but they don't
 throw exceptions.

 Another option is to change the regex used for FS (float suffix) from
 [FflL] to something which encompasses the TS 18661 types, e.g.
 `([FfLl]|d[dfl]|D[DFL]|[fFdD][0-9]+x?)`. But that also requires the
 suffix-handling logic in t_ANY_float to change accordingly.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3331#comment:20>
GRASS GIS <https://grass.osgeo.org>