Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100816
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.216.172 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CA+kxMuT7E3s5-bmLUasdXSB2MePPP9JNft_uXV-ViJK-QP+_1g@mail.gmail.com>
References: <CAOV5rgZ57dezubTW_GVDHiyO-y3Z+n2=iF+PDTMe14RrK3VS_g@mail.gmail.com>
 <CA+kxMuT7E3s5-bmLUasdXSB2MePPP9JNft_uXV-ViJK-QP+_1g@mail.gmail.com>
Date: Tue, 3 Oct 2017 11:21:22 -0400
Message-ID: <CAESVnVot0pK6kROcZCJqN=0_sqCHWkKnhdhfPHN9r7AR=--B=A@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: nyamsprod the funky webmaster <nyamsprod@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Making stream functions accepting SplFileObject as
 valid parameter
From: pollita@php.net (Sara Golemon)

On Tue, Oct 3, 2017 at 9:44 AM, Dan Ackroyd <danack@basereality.com> wrote:
> On 29 September 2017 at 07:46, nyamsprod the funky webmaster
> <nyamsprod@gmail.com> wrote:
>>
>> I've been following the resolution of this bug:
>>
>> https://bugs.php.net/bug.php?id=44392
>>
>> and it seems that there is no safe way to expose the internal
>> `SplFileObject` filepointer.
>
>
> It seems that people are scared to comment on a streams related question...
>
Nah, just distr... OOH SHINY!

> I'm not sure that making stream_* functions accept SplFileObject's
> would be an appropriate way to solve this problem; it's just too much
> of a hack.
>
Implementation wise, about as difficult as you'd imagine.  We have
php_stream_from_zval() which is a central place which could be made
smarter, though most (all?) stream related functions have IS_RESOURCE
checks that'd have to be dealt with, so it still means touching the
world.

> However, although it's not safe to expose the underlying file handle
> used by SplFileObject, I think it _might_ be safe to allow the
> SplFileObject to return a stream that represents the file, but with
> the necessary php_stream_ops that aren't safe to use replaced with NOP
> operations, similar to how it is done in the pgsql extension:
> https://github.com/php/php-src/blob/879126a2cedef5b6e1c1f701ade17ca3da9a39ec/ext/pgsql/pgsql.c#L5406-L5409
>
I like this approach in the abstract (though I haven't paged in the
entire problem space yet).  A proxy wrapper provides (possibily
implemeted on the SplFileObject itself) keeps the scope of the change
localized to SPL and has little residual hack smell.

-Sara