[GRASS5] procedures, "r.mapcalc bug" - really gis lib - see [bug #1502]

[Scott W. Mitchell]

I've been looking at bug #1502, which talks about cases where
r.mapcalc crashes in certain situations with a formula that looks at
categories, and a lookup of a category for a no data condition occurs
(very summarized, see the bug tracker for details).  Looks like I've just
run into this bug in my own work, so I was glad to find a reference to it.

Since I didn't have the email thread to reply to, I used the 
"Comment" button in the RT web interface to report a code adjustment that
I tried on a local copy of the CVS HEAD source.  I thought my report
would get propagated out to the mailing list, but apparently not.

Anyways, my interpretation of what Glynn said would probably be the
appropriate fix certainly stops the error.  I wouldn't mind confirmation,
though, that I understood correctly.

I made a small change in quant.c, home of G_quant_get_cell_value, to check
for a return from G_quant_get_rule_for_d_raster_val before calling
quant_interpolate:

bouteloua:/usr/local/src/grass/src/libes/gis> diff -u quant.c
~/grassmods/libes/gis/quant.c
--- quant.c     1999-12-29 10:10:30.000000000 -0500
+++ /home/smitch/grassmods/libes/gis/quant.c    2003-03-18
14:38:21.000000000 -0500
@@ -812,7 +812,10 @@
   if (! NO_FINITE_RULE)
   {
       p = G__quant_get_rule_for_d_raster_val (q, dcellVal);
-      return quant_interpolate (p->dLow, p->dHigh, p->cLow, p->cHigh,
+      if (! p)
+             return NO_DATA;
+      else
+             return quant_interpolate (p->dLow, p->dHigh, p->cLow,
p->cHigh,
                                  dcellVal);
   }
   

This seems to work for me, hopefully if this is the right change we can
apply it ?  I'm new to this, let me know if I'm interpreting / suggesting
incorrectly.

Thanks,

Scott Mitchell
smitch at eos.geog.utoronto.ca