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 <[email protected]> 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, <[email protected]> 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. >> >>
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
