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
