Edit report at https://bugs.php.net/bug.php?id=44392&edit=1
ID: 44392
Updated by: cmb@php.net
Reported by: php at benjaminschulz dot com
Summary: getFilePointer() for Childs of SplFileObject
-Status: Analyzed
+Status: Wont fix
Type: Feature/Change Request
Package: SPL related
PHP Version: 5.3CVS-2008-03-10 (CVS)
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
This can't be implemented, since the SplFileObject internally
tracks its state (e.g. the current_line), so any change to the
exported file pointer would mess up the objects state. While it
would be possible to export a duplicated file pointer, this
already can basically be archived in userland.
I think that something like nyamsprod's suggestion is actually
what would make sense, but that would require the RFC process[1].
[1] <https://wiki.php.net/rfc/howto>
Previous Comments:
------------------------------------------------------------------------
[2017-01-22 16:10:53] danack@php.net
It might not be possible to implement this in anything close to a safe way. The code assumes that
the internal file resource isn't closed by anything outside of the SplFileObject, and has no
checks against whether the file resource is closed externally.
As there is no check, a segfault can occur if the file has been closed:
==13354== Process terminating with default action of signal 11 (SIGSEGV)
==13354== Bad permissions for mapped region at address 0x0
==13354== at 0x0: ???
==13354== by 0x6A9DBC: _php_stream_fill_read_buffer (streams.c:675)
==13354== by 0x6A9EE6: _php_stream_read (streams.c:722)
==13354== by 0x606774: zim_spl_SplFileObject_fread (spl_directory.c:2932)
For the Curl use-case, you should be able to work around it, just by opening the file again
directly.
curl_setopt($ch, CURLOPT_INFILE, fopen($splFileObject->getRealPath()));
------------------------------------------------------------------------
[2017-01-22 13:30:39] danack@php.net
I've created a PR for this based on Jordan's patch: https://github.com/php/php-src/pull/2328
------------------------------------------------------------------------
[2015-01-14 20:28:06] mattsch at gmail dot com
The Streamable interface sounds like a great idea. Now is this bug ever going to get prioritized?
------------------------------------------------------------------------
[2014-05-13 14:50:45] nyamsprod at gmail dot com
Even thought making the SplFileObject::getFilePointer() method public would be a great addition I
think there is a better solution which would be to create a abstract interface "Ã la"
Traversable but called "Streamable".
This interface would not be implemented alone but classes that implement it like SplFileObject would
be usable directly on function like stream_append_filter, streamp_get_metadata of even curl_setopt.
That way the SplFileObject file pointer would be "usable" but its file pointer property
would remain protected from a developer who would otherwise use the SplFileObject::getFilePointer()
result direclty on a fclose function.
------------------------------------------------------------------------
[2013-12-04 13:05:20] drgomesp at gmail dot com
Any updates on this? It would be really useful to change the visibility of this method to public.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=44392
--
Edit this bug report at https://bugs.php.net/bug.php?id=44392&edit=1