[GRASS-dev] r.univar: allow multiple rasters to be processed
glynn at gclements.plus.com
Wed Mar 12 15:10:23 EDT 2008
Ivan Shmakov wrote:
> >> Is there some fundamental reason why r.univar has separate cases for
> >> CELL/FCELL/DCELL types, rather than just working in DCELL
> >> throughout?
> > I can't remember with any certainty why I did it that way; it's been
> > like that since the first CVS checkin.
> Please consider the following patch.
> RASTER_MAP_TYPE map_type;
> + void *all_values
> + = ((! param.extended->answer) ? 0
> + : (map_type == DCELL_TYPE) ? stats->dcell_array
> + : (map_type == FCELL_TYPE) ? stats->fcell_array
> + : stats->cell_array);
map_type hasn't been initialised yet. There's no reason why it can't
be initialised in the declaration, i.e.:
RASTER_MAP_TYPE map_type = G_get_raster_map_type (fd);
> + size_t value_sz
> + = ((map_type == DCELL_TYPE) ? sizeof (DCELL)
> + : (map_type == FCELL_TYPE) ? sizeof (FCELL)
> + : sizeof (CELL));
We have G_raster_size() for this:
size_t value_sz = G_raster_size(map_type);
> + memcpy (all_values + stats->n * value_sz,
> + ptr, value_sz);
all_values is a void*, and arithmetic on a void* isn't permitted by
ANSI C (gcc allows it as an extension).
We have G_incr_void_ptr() for this, e.g..:
memcpy(G_incr_void_ptr(all_values, stats->n * value_sz),
Or you can just make it a char* instead.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev