Re: C-FFI, results, conditions

Thanks!

This appears to work beautifully, even when using melange. :)

Will have to work this into my blog post explaining C-FFI stuff ...

 - Bruce



On Thu, Jan 17, 2013 at 2:53 AM, Thomas Chust <[email protected]> wrote:

> On Wed, 16 Jan 2013, Bruce Mitchener wrote:
>
>  [...]
>>
>> When wrapping an API with C-FFI (either directly or via melange
>> generating C-FFI), I often run into a situation where I have a function
>> that returns 0 or an error code.
>> I'd like to be able to have the C-FFI know how to pass the result to a
>> mapping function which would check for non-zero and then signal a
>> condition as appropriate.
>> [...]
>>
>
> Hello,
>
> if there are many functions returning the same type of result that needs
> to be checked, wouldn't a C-mapped-subtype for the results make sense?
>
> For all those C library functions that return positive integer handles or
> a negative number to indicate failure I would probably write code like this:
>
>   define C-variable C-errno :: <C-int>
>     c-name: "errno";
>   end;
>
>   define C-function C-strerror
>     parameter errno :: <C-int>;
>     result message :: <C-string>;
>     c-name: "strerror";
>   end;
>
>   define class <syscall-error> (<error>)
>     constant slot status :: <integer>, required-init-keyword: status:;
>     constant slot message :: <string>, init-keyword: message:, init-value:
> "Unknown error";
>   end;
>
>   define constant <nonnegative-integer> = limited(<integer>, min: 0);
>
>   define C-mapped-subtype <C-int-or-error> (<C-int>)
>     import-map <nonnegative-integer>, import-function:
>       method (result :: <integer>) => (checked :: <nonnegative-integer>)
>         if (result < 0)
>           let errno = C-errno();
>           error(make(<syscall-error>, status: errno, message:
> C-strerror(errno)));
>         else
>           result;
>         end;
>       end;
>   end;
>
>   define C-function C-open
>     parameter path :: <C-string>;
>     parameter flags :: <C-int>;
>     result handle :: <C-int-or-error>;
>     c-name: "open";
>   end;
>
>   ...
>
> I would probably also take an analogous route in SWIG and define a special
> type map for these return values which would include the error handling
> code.
>
> If this solution sucks for some reason, my next idea would be to just
> write a macro wrapping C-function-definer with additional syntactic sugar
> for the generation of complex wrapper functions.
>
> But it's been a while since I actually wrote something in Dylan, so I
> wouldn't be surprised if my code didn't meet the style guidelines or if
> there were much better solutions I overlooked ;-)
>
> Ciao,
> Thomas
>
>
> --
> When C++ is your hammer, every problem looks like your thumb.
> ______________________________**_________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/**mailman/listinfo/hackers<https://lists.opendylan.org/mailman/listinfo/hackers>
>

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers