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

[GRASS GIS]

#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 glynn):

 Replying to [comment:11 hamish]:
 > One thing it may be, that I haven't tried is if GRASS is built without
 the gcc -g debugging flag. I always build with that and AFAIU that means
 all variables are initizalied to '\0' (null).

 No. Static variables (global variables and local variables with the
 "static" qualifier") without an explicit initialiser are implicitly
 initialised to zero regardless of the compiler options used. This
 behaviour is mandated by the C standards. A static variable's initial
 value is stored in the binary, so it isn't possible for a static variable
 to be uninitialised.

 [However, variables which are initialised to zero, explicitly or
 implicitly, are all stored in the BSS segment. As the entire segment
 contains only zeros, it can be "compressed" to nothing. Nonetheless,
 everything within that segment is initialised to zero at startup.]

 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).

 Also, enabling or disabling optimisations may affect what happens to be
 stored in a particular section of uninitialised memory, even if it doesn't
 affect whether or not initialisation occurs.

 However:

 > If there is a test that some empty variable == NULL, such as
 r.li.daemon/worker.c's {{{  if (ad->mask_name == NULL) {  }}}, and that
 variable is not explicitly made empty upon creation and then used
 uninitialized.... well, it's a theory.

 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).

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