[CM] On FFI bindings
Christos Vagias
chris.actondev at gmail.com
Thu Oct 22 17:15:20 PDT 2020
Another thought on the semantics:
- keep init_func behavior as it is (legacy, snake_case, backward
compatibility)
- passing init-func (kebab-case) new behavior: calling with the entrypoint
in the same manner as
the FFI functions: s7_scheme* sc , s7_pointer args. args being
(the-passed-env 'args) : being either
something or #f
Wonder if there's a point in having the called entry point also return
s7_pointer. It would be
elegant though as far as consistency goes: calling any s7 FFI function as
the init-func.
Possible use: init-func returning an environment with bindings.
On Thu, 22 Oct 2020 at 22:18, Christos Vagias <chris.actondev at gmail.com>
wrote:
> If I understood correctly you get a segfault when having the C function
> with 2 args (s7_scheme and s7_pointer)
> but passing only s7_scheme.
>
> This seems relevant:
> https://stackoverflow.com/questions/12572575/i-can-call-a-function-imported-with-dlsym-with-a-wrong-signature-why
> and particularly the answer saying
> "C uses cdecl call conversion (so caller clears the stack) [..]
> But actually behavior is undefined"
>
> In any case, I'm really noob in this area so that's all I can contribute.
>
> So my 2 cents:
> - when not having passed init_args: calling the C init_func(s7_scheme)
> (serving also as backwards compatibility)
> - when init_args is present, calling init_func(s7_scheme, s7_pointer)
>
> On Thu, 22 Oct 2020 at 21:57, <bil at ccrma.stanford.edu> wrote:
>
>> > how does C behave if you assume that the called function has a
>> > signature
>> > of (s7_scheme* sc) and you try to pass (s7_scheme* sc, s7_pointer args)
>> > ?
>>
>> I tried it with the tlib example, and if you declare args in C, but
>> don't pass them in scheme (i.e. no init_args in the environment),
>> I get a segfault. The other way (no args declared, but you pass and
>> use them anyway) seems to work -- strange! This is in gcc 10.2
>> in Linux.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20201023/655f2fe1/attachment.html>
More information about the Cmdist
mailing list