add a protected member function to SplFileObject so that extending classes can have more control of the file handle... patch included against php5.2.6..


--- php-5.2.6/ext/spl/spl_directory.c   2008-02-13 04:23:26.000000000 -0800
+++ php52GetResource/ext/spl/spl_directory.c    2008-11-14 13:22:17.000000000 -0800
@@ -2218,6 +2218,15 @@
        }
 } /* }}} */

+/* {{{ proto void SplFileObject::getFileResource()
+   Seek to specified line */
+SPL_METHOD(SplFileObject, getFileResource)
+{
+       spl_filesystem_object *intern = (spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
+
+       php_stream_to_zval(intern->u.file.stream, return_value);
+} /* }}} */
+
 /* {{{ Function/Class/Method definitions */
 static
 ZEND_BEGIN_ARG_INFO_EX(arginfo_file_object___construct, 0, 0, 1)
@@ -2310,6 +2319,7 @@
        SPL_ME(SplFileObject, getMaxLineLen,  NULL, ZEND_ACC_PUBLIC)
        SPL_ME(SplFileObject, hasChildren,    NULL, ZEND_ACC_PUBLIC)
        SPL_ME(SplFileObject, getChildren,    NULL, ZEND_ACC_PUBLIC)
+       SPL_ME(SplFileObject, getFileResource,NULL, ZEND_ACC_PROTECTED)
        SPL_ME(SplFileObject, seek,           arginfo_file_object_seek,          ZEND_ACC_PUBLIC)
        /* mappings */
        SPL_MA(SplFileObject, getCurrentLine, SplFileObject, fgets,      NULL, ZEND_ACC_PUBLIC)

What's the status of this bug?  SplFileObject is supposed to be an OO version of fopen but it's quite useless to pass into other functions like curl when those functions expect a resource.

Example:

$splFileObject = new SplFileObject('/tmp/foo', 'r');
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'sftp://server.com/folder/');
curl_setopt($ch, CURLOPT_UPLOAD, 1);
curl_setopt($ch, CURLOPT_INFILE, $splFileObject); # <-- won't work, must be file resource
curl_setopt($ch, CURLOPT_INFILESIZE, filesize($localfile));
curl_exec ($ch);
curl_close($ch);

I don't see why this method shouldn't be public. I vote for extending its 
visibility to public.

I agree that this method should also be public.  Please implement this method ASAP.

Any updates on this? It would be really useful to change the visibility of this method to public.

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.

The Streamable interface sounds like a great idea.  Now is this bug ever going to get prioritized?

I've created a PR for this based on Jordan's patch: https://github.com/php/php-src/pull/2328

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()));

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>