Yellow, On Tue 26 Jan 2010 23:29, l...@gnu.org (Ludovic Courtès) writes:
>> By "dynamic", I mean that you don't have to write C and compile it; you >> can do everything at runtime from Scheme. You use dynamic-func and >> dynamic-link to get the raw function pointer, and make-foreign-function >> to turn that function pointer into a Scheme procedure. >> >> The interface is very low-level. Obviously declaring that an arbitrary >> symbol resolved via `dlsym' is of a certain function type is an unsafe >> operation that can lead to crashes. > > If it’s in a module of its own, then users will (in theory) be able to > prevent its use by “untrusted” code, which would be fine. Well, yes. But anyone who has to make a sandbox should be specifying the set of bindings that are available, not the set that are restricted. But yes, I think we are in agreement hee. > One thing that would be neat is to integrate nicely with GNU ld’s symbol > versioning (it would work around some of the safety lost by not > compiling actual C code.) For instance, one would be able to say: > > (dynamic-func "foo" lib "FOO_0.2") > > That would use dlvsym() on GNU and ignore the last argument on other > systems. (Though ideally ltdl would provide a wrapper for dlvsym). Indeed this would be neat. I think ltdl is the right place for this to go. >> I would merge it now, except for the fact that it depends on libffi. >> Libffi is very portable, and probably exists for all of Guile's >> architectures, but it is an extra dependency. Should we require libffi >> in Guile 1.9.8? Or should we build the necessary pieces conditionally? > > Well, it’s always annoying to add a dependency, but OTOH it was bound to > happen. So... let’s go? Wow, ok. Well yes, we did always think this was going to happen... so all right. I'll see what it takes, and merge when ready. Andy -- http://wingolog.org/
