nicolas cellier wrote:
> FFI is unsafe of course as C code is unsafe.

No, that's only true for plugins. For the FFI it's a lot worse. Even if 
you have a perfectly safe function foo in bar.dll how do you prevent a 
malicious attacker instead to, e.g., execute "format c:" from 
"system.dll"? The FFI won't care.

> But you have to explain why a plugin would be safer.

A plugin provides access that has been explicitly granted. You write a 
primitive in a plugin to provide access to that function and NO MORE. 
Without the FFI for example, it is not possible to divert any of the 
plugins to do the moral equivalent of "format c:". For plugins your 
statement is correct - the plugin is as safe as the code it uses and if 
there is a bug in the underlying C code that bug might be exploited. But 
beyond that, there is no authority that a plugin grants.

> In the plugin case, user has to deal with pointers on data too, he has to do 
> conversions by hands where FFI would automate part of this process and he has 
> to be extremely carefull with object creation that might break previously 
> collected pointers in Smalltalk space.

This is true in both situations. Unless you consider utterly trivial 
examples, managing complex data structures using the FFI is a nightmare 
- one of the reasons why I prefer to deal with them plugin-style.

> So, the plugin are maybe safer because only a few well experienced and well 
> behaved programmers dare jump the hurd, in a word because it is rarely 
> used...

Given the amount of plugins and the amount of FFI usage I think plugin 
usage outnumbers FFI usage by an order of magnitude at least.

Cheers,
   - Andreas