Re: Making stream functions accepting SplFileObject as valid parameter
| From: | Dan Ackroyd | Date: | Tue, 03 Oct 2017 13:44:18 +0000 |
| Subject: | Re: Making stream functions accepting SplFileObject as valid parameter | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100812@lists.php.net to get a copy of this message | ||
On 29 September 2017 at 07:46, nyamsprod the funky webmaster
<nyamsprod@gmail.com> wrote:
> Hi internals,
>
> 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.
Hi nyamsprod the funky webmaster,
It seems that people are scared to comment on a streams related question...
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.
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
static int php_pgsql_fd_close(php_stream *stream, int close_handle) /* {{{ */
{
return EOF;
}
To expose the internal stream to userland.
I'd really like to hear from anyone who knows about streams internals
to know if that's a viable approach.
cheers
Dan
Ack