[GRASS-dev] Re: [GRASS GIS] #660: v.delaunay producing incorrect results

[GRASS GIS]

#660: v.delaunay producing incorrect results
-----------------------+----------------------------------------------------
  Reporter:  cmbarton  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect    |      Status:  new                      
  Priority:  critical  |   Milestone:  6.4.0                    
 Component:  Vector    |     Version:  6.4.0 RCs                
Resolution:            |    Keywords:  delaunay                 
  Platform:  MacOSX    |         Cpu:  OSX/Intel                
-----------------------+----------------------------------------------------
Comment (by mmetz):

 Replying to [comment:21 marisn]:
 > Replying to [comment:16 mmetz]:
 > > Please try attached patch in verbose mode.
 > >
 > > Markus M
 > On my Linux box still works just fine. Only question is regarding this
 warning. Is it OK to ignore?
 {{{
 ==10913== Syscall param write(buf) points to uninitialised byte(s)
 ==10913==    at 0x749D210: __write_nocancel (syscall-template.S:82)
 ==10913==    by 0x7447422: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1268)
 ==10913==    by 0x7447099: new_do_write (fileops.c:522)
 ==10913==    by 0x74473C4: _IO_do_write@@GLIBC_2.2.5 (fileops.c:495)
 ==10913==    by 0x7448CC6: _IO_switch_to_get_mode (genops.c:189)
 ==10913==    by 0x7447AB7: _IO_file_seekoff@@GLIBC_2.2.5 (fileops.c:978)
 ==10913==    by 0x743CD0B: ftell (ioftell.c:41)
 ==10913==    by 0x5D22F8B: dig__write_head (head.c:56)
 ==10913==    by 0x4E568BE: V1_open_new_nat (open_nat.c:127)
 ==10913==    by 0x4E55A7B: Vect_open_new (open.c:565)
 ==10913==    by 0x40309B: main (main.c:106)
 ==10913==  Address 0x4036009 is not stack'd, malloc'd or (recently) free'd
 }}}

 This warning is a complete mystery to me, it shows up with some vector
 modules but not with others, therefore I would say it is safe to ignore.
 The beginning of v.delaunay is nearly identical with v.voronoi, but
 v.voronoi does not show this warning?

 AFAICT, this warning appears because the file pointer for the coor file
 points to the end of the coor file (uninitialised bytes), but that's what
 it's supposed to do.

 Markus M

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