[bug #3117] [GRASS-dev] povray and grass

[Glynn Clements]

Markus Neteler wrote:

> > [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".
> 
> Apparently this needs to be better documented. Where?

It's the first section (after "Introduction") in the libgis
documentation:

http://mpa.itc.it/markus/grass61progman/gislib.html#init

    Library Initialization
    
    It is mandatory that the system be initialized before any other
    library routines are called.
    
    int G_gisinit(char *program_name) initialize gis library

[snip]

I'm not sure that it can be made much clearer than that (especially as
"mandatory" is in bold type).

OTOH, the front page of the Programmer's Manual simply lists all of
the libraries in alphabetical order, with libgis treated as just one
of many libraries, when it's really rather more important than e.g. 
the bitmap or btree libraries.

> > OTOH, the bug in v.in.ogr is very likely to cause problems. In order
> > for alternate execution modes (--help, --tcltk etc) to work, it is
> > essential that the module doesn't attempt to actually do /anything/
> > except declare its options until after G_parser() returns (/if/ it
> > returns, which it won't if any of the alternate execution modes are
> > used).
> > 
> > Module authors/maintainers need to stop overlooking this issue.
> > 
> > Based upon past experience, this may require that they are forced to
> > stop overlooking this issue, e.g. by making most functions generate a
> > fatal error if called before G_parser().
> 
> This might be a good idea to actually catch such problems.
> Since there are often *many* authors/maintainers, and code sometimes
> originates from 20 years back, we have to enforce it.
> 
> There are a couple of candidates which do calculations within
> the parameter/flag definition part.

Yes; those are the most common reasons/excuses for reading the state
before G_parser() returns.

This has already caused problems with e.g. --html-description,
requiring the construction of a temporary mapset in order to generate
the HTML pages, due to modules requiring a valid mapset simply to
generate help text, HTML pages or the Tcl/Tk UI code. ISTR that a few
modules tried to use the active monitor; I don't know if they have
been fixed yet.

> > [I suspect that this can be implemented by adding checks to a few core
> > functions, e.g. G_getenv(), G_get_window() etc. Anything which doesn't
> > call those is probably safe to call at any point.]
> > 
> > Future developments are likely to make this more important. E.g. it
> > ought to be possible to override most GRASS state using command-line
> > switches. Of course, command-line switches won't have any effect until
> > G_parser() has been called. If a module calls GRASS functions which
> > access such state prior to calling G_parser(), it will use the wrong
> > state and thus get the wrong results.
> > 
> > Just in case it isn't clear, the only functions which can legitimately
> > be called before G_parser are:
> > 
> > 	G_gisinit
> > 	G_no_gisinit
> > 	G_define_module
> > 	G_define_flag
> > 	G_define_option
> > 	G_define_standard_option
> > 	G_disable_interactive
> 
> Question: Why does d.vect work since G_gisinit() comes right
> before G_parser()? Because the definition part is "clean"?

Yes. The G_define_* functions (and G_gettext(), used by the _() macro)
are (currently) sufficiently trivial that they don't depend upon
library initialisation. The only thing which could go wrong is if
G_malloc() fails to obtain enough memory for a Flag/Option struct
(which is highly unlikely).

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