[GRASS-dev] raster row alloc?

Glynn Clements glynn at gclements.plus.com
Tue Jun 6 00:21:35 EDT 2006


Hamish wrote:

> > > > I'd like to use  G_set_null_value(array, nrows*ncols, map_type);
> > > > to fill some nrows with NULL in one go instead of a loop over the
> > > > number of rows, and perhaps G_raster_cpy() to copy a few lines
> > > > over at a time.
> > > >
> > > > nrows*(ncols+1) ?
> > >
> > > Not necessary.
> > 
> > Glynn, as lovely as your succinct answers are, would you be able to
> > clarify whether you meant that Hamish's wish is not necessary or if
> > the the "+1"  in "nrows*(ncols+1)" is not necessary to perform this
> > action?
> 
> +1 isn't necessary; nrows*ncols is enough. i.e. you can copy chunks of
> memory without worrying about stopping on each individual line.
> 
> I think it might be a common mistake to do (at least it is one I've
> done in the past):
> 
> row_array = G_allocate_raster_buf(map_type);
> ptr = row_array;
> loop {
>  ptr = G_incr_void_ptr(ptr, G_raster_size(map_type));
>  G_set_raster_value_d(ptr, value, map_type);
> }
> 
> when the order should be:
> 
> row_array = G_allocate_raster_buf(map_type);
> ptr = row_array;
> loop {
>  G_set_raster_value_d(ptr, value, map_type);
>  ptr = G_incr_void_ptr(ptr, G_raster_size(map_type));
> }
> 
> By allocating an extra byte for row_array you mitigate the effect
> of this sort of dumb mistake. It doesn't cost much for a single row, 
> and the bug doesn't have an effect as long as you are consistently +1.

The former will result in the data being out of place by one column,
which is still a bug; possibly worse than a crash.

I thought that it might have been related to the "nbytes" prefix at
the beginning of each line in a raster file, but the internal buffers
(G__.work_buf etc) aren't allocated using those functions.

It might be a precaution against writing to buf[n] where n is
incorrectly constrained to "<= cols" rather than "< cols". By
allocating an extra cell, an erroneous write will be ignored rather
than overwriting something important.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list