[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.

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.

--
Christoph M. Becker

Hi Sara,

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,

-----Original Message-----
From: Sara Golemon pollita@php.net
Sent: Tuesday, December 11, 2018 5:20 PM
To: Dmitry Stogov dmitry@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

People who don't know what FFI is, don't need it.

I think this is a very dangerous way of designing, writing and documenting
software.

I appreciate your efforts in pushing this forward, but please reconsider
when approaching the naming problematic, because this point of view is
extremely flawed.

I'm fine with FFI and it matches other scripting languages (python,
ruby, lua). Not saying that's the reason to not change it but seems to
me the name is most appropriate in its field; I see no harm.

• Markus