[GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

[Glynn Clements]

Martin Landa wrote:

> > Unfortunately GRASS 7 moved ahead towards its aim "to make life harder
> > for anyone trying to use the GRASS libraries" [1]. Basically more and
> 
> personally I am not fan of this approach. I still think that we should
> provide in GRASS API function like G_set_fatal_error() with default
> value G_FATAL_ERROR_EXIT (current behaviour). The second option would
> be G_FATAL_ERROR_RETURN with big big warning in the API manual that
> you are living GRASS libraries in completely unpredictable state

You're misunderstanding a key point.

Returning from G_fatal_error() won't leave GRASS libraries in an
unpredictable state. It's "escaping" from G_fatal_error() via e.g. 
longjmp() (so that control doesn't return to the caller) that will do
that.

Returning from G_fatal_error() will typically result in a
(more-or-less immediate) segfault when the caller tries to use data
structures which contain garbage (because the callee never initialised
them, but raised a fatal error instead).

The simplest example is G__malloc():

    buf = malloc(n);
    if (!buf) {

	...

	G_fatal_error(_("G_malloc: unable to allocate %lu bytes of memory at %s:%d"),
		      (unsigned long) n, file, line);
    }

    return buf;

If malloc() returns NULL and the subsequent G_fatal_error() call
returns, G__malloc() will return NULL to its caller. Which will
segfault as soon as it tries to store something in the "allocated"
memory.

The key feature of G_fatal_error() isn't printing error messages. The
key feature is that it doesn't return.

It achieves this by calling exit() (or optionally raising SIGSEGV; why
it didn't use SIGABRT, I have no idea). Calling longjmp() would work. 
If it was C++, raising an exception would work. Returning will *not*
work.

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