[GRASS-dev] Re: [GRASS GIS] #718: r.li forgets mask/illegal filename

GRASS GIS trac at osgeo.org
Fri Aug 14 23:09:24 EDT 2009

#718: r.li forgets mask/illegal filename
  Reporter:  kyngchaos  |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect     |      Status:  new                      
  Priority:  normal     |   Milestone:  6.4.0                    
 Component:  Raster     |     Version:  6.4.0 RCs                
Resolution:             |    Keywords:  r.li                     
  Platform:  All        |         Cpu:  All                      
Comment (by hamish):

 Replying to [comment:13 glynn]:
 > Automatic variables (local variables lacking the "static"
 > qualifier) without an explicit initialiser are normally
 > uninitialised; I have seen compilers which will initialise such
 > variables (not necessarily to zero) in debug mode, but I've never
 > seen gcc do it (gcc's -g switch controls whether or not debug
 > info is added to the output file; it doesn't affect code
 > generation in any way, unlike e.g. MSVC where "debug mode"
 > disables optimisation by default).
 > ad is a pointer to a structure which is allocated with
 > G_malloc(). This uses malloc, which doesn't normally initialise
 > memory (although, again, some implementations will initialise
 > malloc()d memory in debug mode, but not usually to zero).

 FWIW, my memory was from G_command_history() or somewhere where I used
 strncpy() (which unlike strcpy() doesn't always null terminate) and for me
 (on Debian) there was no problem as the memory space was all 0s to begin
 with & so I didn't notice it. On Markus's system this wasn't true and it
 took a while to figure out until I darkly remembered hearing about this
 before. It may well be a Debianism.

 but anyway, back to the bug, it would seem that worker.c's
 mask_preprocessing() should return NULL for ad->mask_name if
 G_get_cellhd() fails, but I'm unable to reproduce the problem, so...


Ticket URL: <https://trac.osgeo.org/grass/ticket/718#comment:14>
GRASS GIS <http://grass.osgeo.org>

More information about the grass-dev mailing list