[GRASS5] r.neighbors: works with reclass maps?

[Eric G. Miller]

On Fri, 4 Jan 2002 20:34:30 +0000, Glynn Clements <glynn.clements at virgin.net> wrote:

> 
> Markus Neteler wrote:
> 
> > thanks for looking into this! Do you see a chance to work
> > around?
> 
> Sure; I just need to determine how G__.work_buf, G__.mask_buf etc are
> managed, and add another one.
> 
> > I have seen some malloc tests in other "configures"
> > such as GDAL etc. Perhaps they have a functional autoconf
> > implementation?
> 
> The issue is with alloca(). alloca() suffers from lots of
> platform-specific quirks, due the fact that it has to be implemented
> by the compiler.
> 
> Getting autoconf to detect its presence or absence (and implementing a
> workaround if absent) is simple. It's the usage which is messy (see
> the documentation of AC_FUNC_ALLOCA in the autoconf Info file for
> details).
> 
> This is unfortunate, as alloca() is very useful for short-lived
> variable-sized buffers. Whereas alloca() may take only a single CPU
> clock cycle, malloc() and free() can take an arbitrary amount of time. 
> An additional malloc/free per call to G_get_raster_row() could result
> in a significant performance hit.

C99 allows variable length automatic arrays.  Too bad we probably
can't rely on that feature yet (though, it is supported by gcc-3.0).

int foo (int size)
{
	char buff[size];
	....
}

-- 
Eric G. Miller <egm2 at jps.net>