Shiro Kawai <xxxxxx@gmail.com> writes:

> The thing is that Gauche aims at a hybrid of Scheme and general
> list-processing library in C; C API can be called from other C
> functions unrelated to Scheme.
>
> The bottom error handler can examine the Scheme VM state and get info
> from the top frame in the stack. But it isn't necessarily the Scheme
> procedure related to the C API, for the Scheme procedure may be tail
> called, in that case we don't have a frame for it at the time the C
> API is called.

Gauche is not alone in having this kind of structure, which does make it
difficult to make a systematic implementation of SRFI 198. Maybe it's
possible in Gauche with some effort, but e.g. Chez Scheme and Guile can
also mix Scheme and C code, and I find it unlikely that those
implementations would get a systematic SRFI 198 implementation that
covers all foreign errors.

> There's a couple of choices---change all the C API to take some Scheme
> context info (we can reference the current Scheme VM info, but that's
> not enough because of the tail-call problem), or wrap low-level calls
> in srfi-170 to prevent tail-calling bottom-level API.

Is the scope of the problem to solve this for only SRFI 170? If I were
to implement SRFI 170 for Chez then I'd write new C wrappers for each
required C library function, and call them via the FFI. The wrappers
would return the return value & errno to Scheme code, which would then
call SRFI 198 as required. Maybe I'm not seeing something, but is your
problem related to trying to reuse the existing C functions in Gauche
that raise errors themselves?

--
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK