[DGD] More kfun extension questions...

[Foo the Xyzzy Avenger]

Hi list,

I've run into two annoyances recently, one of them minor and the other
one less minor.  The driver seems to already have the infrastructure
necessary to handle both -- the question is, how to do so within the
bounds of the extension interface.

The first minor issue has to do with DGD_ERROR(), which of course
simply calls error().  This latter function has sprintf-like semantics
and allows me to do things like error("Expected ']' but found '%c',
*p), for example.  DGD_ERROR, on the other hand, being a macro, does
not allow this, as it cannot have variable arguments.  My current
workaround is obviously just to use error(), but this makes my kfuns
non-compliant and thus theoretically not upgrade-proof.  Perhaps it
would be better to have DGD_ERROR be defined this way:

#define DGD_ERROR               error

This works fine with gcc, but I'll admit I don't know if it's
portable.  Alternatively, one could actually define DGD_ERROR as a
function somewhere, instead of as a macro.

The more major issue has to do with error handling.  Consider the
following situation: I have a big and complicated kfun that I want to
break down into a bunch of smaller functions.  Somewhere along the
line I allocate memory, and then I call a helper function which
possibly calls another function and so on and so forth until finally
something goes wrong and DGD_ERROR is called.  This invokes a longjmp
and boom, my call to FREE, which was supposed to happen after those
helper functions returned, gets bypassed entirely, resulting in a
memory leak.

In some cases, I can get around this by allocating memory on the stack
instead, but this is undesirable anytime the amount of memory
allocated is a function of some variable that could possibly be set or
influenced by LPC code (for example, the number of arguments passed to
a kfun, or whatever).  I don't want wizards smashing the stack!  So it
has to be the heap, which means an explicit call to free.

Looking at error.c, it appears there is a handler stored in the
context structure, which gets called possibly when error() is called.
I have not examined it enough to know exactly how it works, but in
principle is it possible to have error() call some sort of cleanup
routine before actually longjmp'ing to the error handling code?

Alternatively, of course, I restructure my code in such a way that
helper functions never call error and instead propagate error codes up
to the parent function, free memory, and then substitute error strings
for those codes and call error() with those strings.  Besides being
extremely annoying, this also means that I must have a finite number
of error strings, greatly reducing the amount of useful error
information I can report.

The follow-up question then of course is, if there is some sort of
error handler functionality in place, is the extension interface set
up to use it?

Thanks in advance for any thoughts you can offer!