[RFC] FFI - Foreign Function Interface

Hi Marco, Some API and naming issues may be changed, e.g. FFI::array_type() was renamed to FFI::arrayType(). Changing FFI into ForeignFunctionInterface looks, like an overhead. People who don't know what FFI is, don't need it. I surprised, there are no any problem reports... It seems, like few people on @internals tried it. Thanks. Dmitry. ________________________________ From: Marco Pivetta <ocramius@gmail.com> Sent: Thursday, December 6, 2018 7:26:57 PM To: Dmitry Stogov Cc: PHP Internals List Subject: Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface Looks very interesting, especially for simplifying the landscape of extensions. Still, the amount of abbreviations and naming issues is quite huge: needs a lot of care on that end, IMO. Even just the name of the type (`FFI`) can simply be expanded to `ForeignFunctionInterface`. Just my 2 cents. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On Thu, Dec 6, 2018 at 4:54 PM Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote: Hi Internals, I would like to start discussion of FFI RFC https://wiki.php.net/rfc/ffi This extension allows calling C function and accessing C data structures in pure PHP. In conjunction with preloading it gives a possibility to write PHP extension in PHP itself. The extension was tested on attempt to build TensorFlow PHP binding. Thanks. Dmitry.

On 06.12.2018 at 17:26, Marco Pivetta wrote:

By the same reasoning, http_response_code() is a bad name, and should be changed to hyper_text_transfer_protocol_response_code(). Same for parse_url(), which should better be named parse_uniform_resource_locator(). ;) Don't get me wrong, I'm all for having self-explaining identifiers, but if within a given domain an abbreviation is *very* common, it makes not much sense to spell it out. And FFI is very common when interfacing to C from a scripting language.

Hi Sara, On 12/11/18 7:19 PM, Sara Golemon wrote: On Thu, Dec 6, 2018 at 9:54 AM Dmitry Stogov <dmitry@zend.com<mailto:dmitry@zend.com>> wrote: I would like to start discussion of FFI RFC https://wiki.php.net/rfc/ffi I said this already privately, but I just want to repeat here in the open. This thing is DANGEROUS. Yes. This may be really dangerous, as well as writing an own PHP extension or any C program. I know you know that. I'm not telling you, I'm stating it for every casual reader of this list. So while discussing details of naming and calling conventions is important, my #1 concern is how we avoid creating a potentially fatal situation for users. I like the "ffi.enable=preload" idea you came up with. I think that addresses the actual needs that FFI is trying to solve without completely opening the fire hose. Big +2 to that idea. (Although it's not expressed, I'm assuming this is PHP_INI_SYSTEM as anything else would be silly) Of course "ffi.enable" must be INI_SYSTEM (it's INI_ALL by mistake, I'll fix this and make a note in RFC). I'm not super enthused by having "ffi.enable=true" even be an option, to be quite honest. We may consider removing "ffi.enable=true", or changing its meaning to current "ffi.enable=preload". 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. I think, it's possible to use FFI without PHP extension API knowledge, but good C experience is required. And for the record, since some of my tweetings have been misconstrued, I am currently +1 on the idea as a whole. I just want flashing neon signage a mile high and a heavy, even frustrating barrier to access. The consequences of being too lax are too high. -Sara Thanks. Dmitry.

Hi Sara,

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