Re: [gforth] exit() code in main.c

[Joel Rees]

I only wish I knew what we are talking about here, but this is a topic
of interest to me.

On Wed, Mar 23, 2016 at 2:54 AM, Anton Ertl
<address@hidden> wrote:
> On Tue, Mar 22, 2016 at 06:21:05PM +0100, Bernd Paysan wrote:
>> We have several places in main.c, where non-recoverable bugs happen, and we
>> exit() on them. As Gforth can be used as library now, this is a bad idea - a
>> library should never exit, so the only word that should be allowed to exit is
>> main(). What to do?
>
> Many of these occurences are conditions where recovery by the caller
> of the library will not happen.  So, just like a failed assertion
> exits, it may be acceptable for the caller to exit when the image file
> has the wrong format.

+1

>> C's exception handling with setjmp/longjmp is very poor, and can't be used
>> outside the engine, where we pass the attempt to do some primitive exception
>> handling to CATCH/THROW in Forth. So the probably best way is to define error
>> return values for all the functions that may fail.

+1

The problem being where to pass the failure codes, of course.

> One could certainly have a
>
> jmp_buf gforth_exit;
>
> or something like it, and leave it to the caller of the library to
> initialize it, and the gforth library longjmps to it from the places
> that exit now.

If the gforth runtime doesn't call into the C runtime, I think that should work.

It's clunky, but it's one of the two usual ways C usually overcomes
the bottleneck/straitjacket of mixing parameters with return addresses
on a single stack in the standard runtime, isn't it?

The other being defining the return value as a structure capable of
fitting in however many registers the CPU/runtime-model makes
available for return values, of course.

And then there's the half-solution of dropping extra information in a
global somewhere.

> A harder nut to crack is what to do about the error messages.
> Currently many exit()s are preceded by fprintf(stderr,...).  If we
> don't want to exit() under these circumstances, we probably also don't
> want to output the message.  But if the caller decides to exit after
> all, it will want to output the message.  We could have a buffer for
> doing this.  But if the caller does not always exit, it may need some
> easier machine-understandable indication of what the error is.

For pre-defined error messages, an index to the error message table
could be folded into an integer return value, but I assume we don't
want to put such limits on the error return mechanism?

> However, is it worth going to these lengths?  Will there be any
> applications other than Gforth itself that use Gforth as a library?

I understand that Lua claims the capability of linking into the Lua
runtime from C code as if it were just another set of library
routines. Not being very familiar with Lua, I'm not sure how well they
implement that, and I'm not sure keeping up with Lua is a project goal
anyway.

But it definitely could be useful.

I can also guess that it may require some redefinition of the gforth
runtime to actually implement.

I've found myself playing with these concepts relative to my C
implementation of a near fig model, and I recognize that it requires
some care with the forth runtime model to coordinate access to the
system-level stuff and such.

If I make the time, I'd be trying to write a C compiler suite that
implements a forth compatible common run-time. I've seen that it
requires redefining the forth run-time a bit, too. But I haven't even
been able to finish said forth-in-C. So, for me, such a compiler suite
is a pipe dream.

I'll go back to lurker mode now.

-- 
Joel Rees

Be careful when you look at conspiracy.
Arm yourself with knowledge of yourself, as well:
http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html