On Wed, Dec 12, 2018 at 11:15 AM Anatol Belski <a...@php.net> wrote: > Hi Sara, > > > -----Original Message----- > > From: Sara Golemon <poll...@php.net> > > Sent: Tuesday, December 11, 2018 5:20 PM > > To: Dmitry Stogov <dmi...@zend.com> > > Cc: PHP internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface > > > > I'm not super enthused by having "ffi.enable=true" even be an option, to > be > > quite honest. For CLI, sure but the damage that can be wrought from a > web > > server exposed to the internet is non-trivial. And I'm also going to > let my > > prejudice show: I don't trust someone who doesn't know how to write an > > extension in C to use FFI. Heck, I've seen some extensions that make me > > wince pretty hard, but at least there I feel like they've had to do > something > > more thoughtful than copy-paste an example from stack overflow and > > change a name or two without any concern for how an unmanaged language > > works. > > > IMO ffi.enable=true by default is ok. Clearly there's a concern about the > web server usage. However, to give a parallel, there's a lot modules like > numpy in Python using ctypes and ffi and they're usable with say Django. It > is all a consideration of stability and QA. Developing a module with ffi > will likely require a C debugger to be at hand :) If someone copy-paste ffi > code into their production without an appropriate QA, well - there's > probably no method that could be ever invented to protect against such > practice. One can actually tell same about pure PHP code, that is used > without appropriate testing. Otherwise, given there were established > modules based on FFI, that are installed a responsible way, having more > hurdles than needed were probably a surplus. Hosting providers and other > parties would be able to figure best secure ways to handle this for their > customers anyway. > > Regards > > Anatol >
My feeling has always been that we shouldn't keep powerful features from good developers because other developers might create poor applications/use it incorrectly. -- -- Chase chasepee...@gmail.com
