[GRASS-dev] Limit in number of "variables" for r.mapcalc?

GRASS GIS GRASS GIS developer
1

Hi devs,

is there a limit in the number of "variables" that r.mapcalc accepts
within from 'eval'? If yes, how big is it?

I am trying to feed r.mapcalc's eval with a fairly large number of pixel
modifiers and, given that the final expression is a valid one, the
execution ends with:

    debug=1 ended with error
    Process ended with non-zero return code -11. See errors in the (error)
    output.

Thank you, Nikos

2

* Nikos Alexandris <nik@nikosalexandris.net> [2015-04-25 00:51:30 +0300]:

Hi devs,

is there a limit in the number of "variables" that r.mapcalc accepts
within from 'eval'? If yes, how big is it?

I am trying to feed r.mapcalc's eval with a fairly large number of pixel
modifiers and, given that the final expression is a valid one, the
execution ends with:

    debug=1 ended with error
    Process ended with non-zero return code -11. See errors in the (error)
    output.

Problem resolved.

As I tend to use g.message to print out almost everything while testing
scripts, it seems I hit a limit in g.message this time! r.mapcalc has no
problem dealing with the long and complex expression fed to eval.

So the question is, is there a limit in g.message? Number of characters?
I recall a similar question of mine regarding r.support, but I can't
trace it back.

Thanks, Nikos

3

Nikos Alexandris wrote:

So the question is, is there a limit in g.message? Number of characters?

g.message takes the message via a command-line argument, so it's
limited to any system-imposed limit on the length of an individual
argument or the combined length of the arguments.

But more significantly, G_message() etc use an internal buffer of 2000
bytes. A message longer than that probably won't work and may well
cause the g.message to crash.

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

4

On Mon, Apr 27, 2015 at 1:16 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

But more significantly, G_message() etc use an internal buffer of 2000
bytes. A message longer than that probably won't work and may well
cause the g.message to crash.

How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long
and using it in
general/g.message/main.c as well to avoid a buffer overflow?

Markus

5

Markus Neteler wrote:

> But more significantly, G_message() etc use an internal buffer of 2000
> bytes. A message longer than that probably won't work and may well
> cause the g.message to crash.

How about (ab)using GPATH_MAX (include/gis.h) which is 4096 chars long
and using it in
general/g.message/main.c as well to avoid a buffer overflow?

Having g.message limit the length of a message would work for
g.message.

For G_message() etc, using vsnprintf() would work, but that's C99.

G_vasprintf() should work, but our private implementation (used if
asprintf() doesn't exist) also requires C99.

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