On Tue, Oct 3, 2017 at 9:44 AM, Dan Ackroyd <dan...@basereality.com> wrote: > On 29 September 2017 at 07:46, nyamsprod the funky webmaster > <nyamsp...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
