[GRASS-dev] [GRASS GIS] #2624: r.horizon problem in Windows (horizon_zud)

GRASS GIS trac at osgeo.org
Fri Jul 17 06:31:46 PDT 2015


#2624: r.horizon problem in Windows (horizon_zud)
-------------------------+-------------------------------------------------
  Reporter:  rorschach   |      Owner:  grass-dev@…
      Type:  defect      |     Status:  new
  Priority:  major       |  Milestone:  7.0.1
 Component:  LibGIS      |    Version:  7.0.0
Resolution:              |   Keywords:  r.horizon, r.sun, wingrass,
       CPU:              |  basename.c
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------
Changes (by andrei):

 * cc: andrei (added)
 * keywords:  r.horizon, r.sun, wingrass => r.horizon, r.sun, wingrass,
     basename.c
 * component:  Raster => LibGIS
 * platform:  MSWindows 8 => Unspecified
 * priority:  normal => major


Comment:

 this has its origin in grass/trunk/lib/gis/basename.c on lines:

 {{{
 91              sprintf(intfmt, "%%0%zud", ndigits);
 96              sprintf(decfmt, "_%%0%zud", ndecimals);
 }}}

 My C skills are very rusty and I would not like to make things worse, but
 I think that these two lines have to be changed to:


 {{{
 91              sprintf(intfmt, "%%0%u", ndigits);
 96              sprintf(decfmt, "_%%0%u", ndecimals);
 }}}

 and the problem would be solved. I'm not that good with old-school format
 specifiers, but I have internet and there's no %z format specifier.

 This problem appeared after this discussion
 [[https://trac.osgeo.org/grass/ticket/2136|2136]] that decided that all
 basename functionality should be moved to this file.

 This makes every module that outputs multiple files with file names like
 basename_001, basename_002, etc (and uses basename.c), unusable, since all
 output files will be named ''basename_zud'' and each will overwrite the
 previous result. In the end these modules will only leave the last result
 as final output.

 In my opinion this is at least a major bug, if not critical since it can
 cause loss of data if the overwrite option is used.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2624#comment:3>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list