Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103602
MIME-Version: 1.0
References: <BY1PR02MB126022AD4151506F6486D6A7BFA90@BY1PR02MB1260.namprd02.prod.outlook.com>
 <CAESVnVoPensNBBymLAEbqJ4PTDXKKwqBYLB9=ZkJU83CnXXZMA@mail.gmail.com> <HE1PR05MB4665C9B5A6CBA44F6A06C527BAA70@HE1PR05MB4665.eurprd05.prod.outlook.com>
In-Reply-To: <HE1PR05MB4665C9B5A6CBA44F6A06C527BAA70@HE1PR05MB4665.eurprd05.prod.outlook.com>
Date: Thu, 13 Dec 2018 10:39:10 -0500
Message-ID: <CAPKYkKxc7DS5o0RtT7CnOJOTHPOOnm_6mMUCRwr5CsJXQo4rZw@mail.gmail.com>
To: Anatol Belski <ab@php.net>
Cc: Sara Golemon <pollita@php.net>, Dmitry Stogov <dmitry@zend.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000060c31a057ce91e61"
Subject: Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000060c31a057ce91e61
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 12, 2018 at 11:15 AM Anatol Belski <ab@php.net> wrote:

> 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
>

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
chasepeeler@gmail.com

--00000000000060c31a057ce91e61--