Hi,
I notice G_allocate_raster_buf() allocates G_window_cols() + 1.
What's the +1 for? Is it just for good luck, is there a null terminator
which inidcates EOL? or something else?
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) ?
???
Hamish
Hamish wrote:
I notice G_allocate_raster_buf() allocates G_window_cols() + 1.
What's the +1 for? Is it just for good luck,
AFAICT, yes.
is there a null terminator which inidcates EOL? or something else?
G_{get,put}_raster_row() etc only read/write G_window_cols() elements.
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 Clements <glynn@gclements.plus.com>
On 6/2/06, Glynn Clements <glynn@gclements.plus.com> 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?
Thanks,
--
-Joel
"Wish not to seem, but to be, the best."
-- Aeschylus
Joel Pitt wrote:
Glynn wrote:
> 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.
Hamish
Joel Pitt 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?
The +1 isn't necessary.
--
Glynn Clements <glynn@gclements.plus.com>
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@gclements.plus.com>