[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:24 neteler]:
 > While we are at it: I found three parsing errors with the patched ctypes
 version (F25, gcc6):
 {{{
 Warning: Could not parse macro "#define serialize_int32_le(buf,x)
 Warning: Could not parse macro "#define serialize_int32_be(buf,x)
 }}}

 Long-standing, harmless. It just means that those definitions won't be
 added to gis.py. It's not as if anything is likely to want them; they
 don't even appear to be used within GRASS itself.

 This:
 {{{
 Error: /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include/stddef.h:427: Syntax
 error at '__attribute__'
 }}}
 might be a problem if it prevents gmath.py from being generated. It can
 probably be worked around with something like:
 {{{
 #ifdef CTYPESGEN
 #undef __attribute__
 #define __attribute__(x)
 #endif
 }}}
 at the top of gmath.h (before including stddef.h).


 This:
 {{{
 Warning: Could not parse macro "#define TGIS STR3DS i5"
 }}}
 is caused by an error in temporal.h; it should be
 {{{
 #define TGIS_STR3DS       5
 }}}
 with an underscore.

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