[postgis-tickets] [PostGIS] #3206: winnie crashing with topology ST_AddModeFace in C commit 9.3 w32 bit run

[PostGIS]

#3206: winnie crashing with topology ST_AddModeFace in C commit 9.3 w32 bit run
-----------------------+---------------------------
  Reporter:  robe      |      Owner:  strk
      Type:  defect    |     Status:  new
  Priority:  blocker   |  Milestone:  PostGIS 2.2.0
 Component:  topology  |    Version:  trunk
Resolution:            |   Keywords:
-----------------------+---------------------------

Comment (by robe):

 Tom Lane also commented and explained.

 http://www.postgresql.org/message-id/15982.1438377791@sss.pgh.pa.us


 ----
 > Issue is when code like this was introduced
 >   appendStringInfo(str, "%s%" PRId64, sep, edge->start_node);

 > Which uses a PostgreSQL function appendStringInfo - as noted here:
 > https://trac.osgeo.org/postgis/ticket/3206

 Huh.  Apparently, whichever Windows compiler you're using defines
 PRId64 as "d", which surely seems pretty broken.

 > I noticed a thread in March on pgsql-hackers that discussed int limits
 > http://www.postgresql.org/message-
 id/20150331141423.GK4878 at alap3.anarazel.de
 > in PostgreSQL and Andres  Freund made this comment which stuck in my
 head:
 > " for another we'd need some uglyness to determine the
 > correct printf modifier for int64_t (can't use PRId64 etc afaics)."
 > What exactly did he mean by can't use PRId64?

 That was about the fact that we don't know whether PRId64 is defined
 as "ld" or "lld" on machines where either of those could legitimately
 mean a 64-bit int.  (And while either would work at runtime in that
 case, we'd get compiler warnings we don't want if we chose the wrong
 one.)  That problem doesn't apply to Windows AFAIK.

 However, some googling suggests that PRId64 isn't defined on all Windows
 build environments, and your report says that there's at least one such
 environment where it is defined, but wrongly :-(.  So that's yet another
 good reason to stay away from PRId64.  You'll notice that it appears
 nowhere in the Postgres sources.

 You did not say how you're declaring the variable that's being printed
 here, but if it's based on the int64 type declared by c.h, you should
 use the INT64_FORMAT or INT64_MODIFIER strings declared by
 c.h/pg_config.h.

                         regards, tom lane


 ----


 So aside from my compiler being possibly broken in some way -- does seem
 like we should stay away from PRI64.  I'm testing using INT64_FORMAT just
 replacing for your appendInfoString calls now.  My compiler warning went
 away and it fixed the sqlmm failure and others.  Though I got to check the
 other 3 why those are still failing:



 {{{
 Creating database 'postgis_reg'
 Loading PostGIS into 'postgis_reg'
 Loading Topology into 'postgis_reg'
 PostgreSQL 9.4.4 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-win32
 -seh-rev1, Built by MinGW-W64 project) 4.8.3, 64-bit
   Postgis 2.2.0dev - r13864 - 2015-07-31 21:35:35
   scripts 2.2.0dev r13864
   GEOS: 3.5.0dev-CAPI-1.9.0 r4064
   PROJ: Rel. 4.9.1, 04 March 2015

 Running tests

  regress/legacy_validate .. ok
  regress/legacy_predicate .. ok
  regress/legacy_invalid .. ok
  regress/sqlmm .. ok
  regress/legacy_query .. ok
  regress/addnode .. ok
  regress/addedge .. ok
  regress/addface .. ok
  regress/addface2.5d .. ok
  regress/addtopogeometrycolumn .. ok
  regress/polygonize .. ok
  regress/st_addisoedge .. failed (diff expected obtained:
 /projects/postgis/tmp/2.2_pg9.4w64/test_12_diff)
  regress/st_addisonode .. ok
  regress/st_addedgemodface .. failed (diff expected obtained:
 /projects/postgis/tmp/2.2_pg9.4w64/test_14_diff)
  regress/st_addedgenewfaces .. failed (diff expected obtained:
 /projects/postgis/tmp/2.2_pg9.4w64/test_15_diff)
  regress/st_changeedgegeom .. ok
  regress/st_createtopogeo .. ok
  regress/st_getfacegeometry .. ok
  regress/st_getfaceedges .. ok
  regress/st_modedgeheal .. ok
  regress/st_modedgesplit .. ok
  regress/st_newedgeheal .. ok
  regress/st_newedgessplit .. ok
  regress/st_remedgenewface .. ok
  regress/st_remedgemodface .. ok
  regress/st_simplify .. ok
  regress/topoelement .. ok
  regress/topoelementarray_agg .. ok
  regress/topogeo_addlinestring .. ok
  regress/topogeo_addpoint .. ok
  regress/topogeo_addpolygon .. ok
  regress/topogeometry_type .. ok
  regress/topojson .. ok
  regress/topologysummary .. ok
  regress/topo2.5d .. ok
  regress/totopogeom .. ok
  regress/droptopology .. ok
  regress/droptopogeometrycolumn .. ok
  regress/copytopology .. ok
  regress/createtopogeom .. ok
  regress/createtopology .. ok
  regress/gml .. ok
  regress/getnodebypoint .. ok
  regress/getedgebypoint .. ok
  regress/getfacebypoint .. ok
  regress/getringedges .. ok
  regress/gettopogeomelements .. ok
  regress/layertrigger .. ok
  regress/validatetopology .. ok
  uninstall .. ok (4336)

 Run tests: 50
 Failed: 3
 Makefile:84: recipe for target `check' failed
 make[1]: *** [check] Error 3
 make[1]: Leaving directory `/projects/postgis/branches/2.2/topology/test'
 Makefile:109: recipe for target `check' failed
 make: *** [check] Error 2
 }}}


 might be just parts of the topology code I missed replacing.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3206#comment:31>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.