[GRASS5] problem with G_get_null_value_row &/or mapset searches in my own program

[Glynn Clements]

Scott W Mitchell wrote:

> I am porting a program written for GRASS4 to "the modern age".  After 
> dealing with a mess of code for a long time, I decided to start largely 
> from scratch, replacing relevant functions with new ones from the 
> GRASS5 API.
> 
> It was going pretty well, I got floating point support working, and 
> decided it was time to tackle the NULL data issue (the previous program 
> just checked for zeros in the input and ignored them).
> 
> The original program reads the whole raster into memory and samples all 
> over this array to gather a bunch of statistics.  I decided to keep 
> this behaviour, since it would be quite awkward to use row-based 
> processing for the algorithm in question.  But I figured I could use 
> G_get_null_value_row to hold a row's worth of data on null/non-null for 
> the one place in the algorithm where this would be useful.
> 
> The trouble is, my program core dumps as soon as it gets to
> G_get_null_value_row(fd, nullbuf, r);

I wouldn't recommend calling that directly; it would be safer to just
scan the data obtained by G_get_*_raster_row() etc for nulls.

> I've compared my program to others in the source tree, and as far as I 
> can see I am using it identically.  So I got it into a debugger and 
> found that the core dump is actually happening "further in", when 
> G_get_cell_hd calls G_is_reclass ...

I don't see how G_get_null_value_row() can end up calling
G_get_cellhd().

> and the arguments in that function 
> call reminded me of another unresolved bug I hadn't got to yet in this 
> software, which is probably my real problem here.
> This other problem is that I've done something wrong, or am missing 
> something important, which is interfering with the module's ability to 
> find files - or maybe it's the ability to keep track of the current 
> mapset.  As part of my rewrite of this program, I got rid of the user 
> interface it had and used the G_parser routines.  I find now that if I 
> give all my arguments on the command line, it seems to start off just 
> fine, and prior to my attempts to support NULL data, it proceeded 
> through to the end of the program, finding all the input it needed and 
> creating output.  But if I tried to use the interactive version 
> (through G_parser's assistance), any parameters that were looking for 
> existing files (rasters and site_lists) in the database could not be 
> found - and typing "list" in response to the prompt always returned an 
> empty list.
> 
> SO - sounds to me like the mapset is "lost", and I don't know why.  As 
> far as I can see I've followed the conventions in r.example and other 
> "real" programs.  I declare my variables, call G_gisinit(), declare all 
> my parameter and flag structures, and call G_parser.  All other 
> programs I've tried from the distributed source are behaving normally 
> (using CVS HEAD, aka grass 5.0.3-cvs).
> 
> I'm hoping this will be some simple, silly, error that will sound 
> familiar to those of you experienced in writing GRASS modules.... 
> anyone ?

No; I don't know of any obvious reason why you might have that
problem.

-- 
Glynn Clements <glynn.clements at virgin.net>