guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fix `get-string-n!' &i/o-decoding exception behavior


From: Andreas Rottmann
Subject: Re: [PATCH] Fix `get-string-n!' &i/o-decoding exception behavior
Date: Mon, 12 Nov 2012 20:52:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> Mark H Weaver <address@hidden> writes:
>>
>>> Why not leave the API as-is, and in the event of an error, just raise
>>> the proper R6RS exception from within 'scm_get_string_n_x'?
>>>
>> The problem here is that we have no easy way to raise R6RS exceptions
>> from C code, AFAICT.  It is certainly possible, but if it involves
>> convoluted code of doing imports of condition types and appropriate
>> constructors, then constructing a proper invocation, all in C, I'd
>> rather avoid it.
>
> It's not that bad.  In Guile 2.0 we have some convenient procedures for
> accessing arbitrary Scheme variables from C.
>
> Looking at your patch, I see that if '%get-string-n!' returned an error,
> then you did:
>
>   (raise (make-i/o-decoding-error port))
>
> This can be written in C as follows:
>
>   scm_call_1 (scm_c_public_ref ("rnrs exceptions", "raise"),
>               scm_call_1 (scm_c_public_ref ("rnrs io ports",
>                                             "make-i/o-decoding-error")));
>
> Alternatively, you could write one or more private helper procedures in
> Scheme to raise R6RS exceptions, and call those private helpers from C
> using 'scm_c_private_ref' instead of 'scm_c_public_ref'.
>
> What do you think?
>
OK, I'll give this approach a try; I suspect it will indeed result in
the least churn.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]