[GRASS-dev] povray and grass

[Glynn Clements]

Hamish wrote:

> > > > Those functions aren't the problem. The problem with v.extract is
> > > > that it's calling them before it calls G_gisinit(), which is
> > > > supposed to be called before any other GRASS function.
> > > > 
> > > > [Apart from anything else, G_gisinit() sets the program name,
> > > > which is used by G_fatal_error(), so anything which might cause
> > > > G_fatal_error() to be called (i.e. almost everything) cannot
> > > > safely be called before G_[no_]gisinit().]
> > > > 
> > > > I have no idea whether or not this actually causes problems at
> > > > present; I'm just pointing out that it's a bug regardless of
> > > > whether or not you happen to "get away with it".
> > > 
> > > Added some comments to lib/gis/parser.c about this for more
> > > visibility. (non-doxygenized header)
> > > 
> > > I notice g.region has fallen afoul of this rule in the last 2 weeks.
> > 
> > I noticed that g.region didn't comply (use of llinfo() and
> > G_{lat,lon}_format_string()) when I updated it to handle GRASS_REGION
> > and WIND_OVERRIDE, but I didn't realise that this was recent.
> 
> The recent change was to call G__get_window() before G_parser() so that
> the llinfo() fn doesn't depend on an uninitialised value.
> 
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/general/g.region/cmd/main.c
> 
> solution is probably to abandon the llinfo() string, it's nice but not
> critical.

Right. If g.region can be made to work without using llinfo(), it
should be.

Modules should assume that the operating environment is undefined
prior to G_parser(). If for no other reason than to ensure that
--help, --html-description etc work even if the operating environment
is invalid (e.g. no $GISRC or mapset).

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