Hi!
I try to do some complex code with custom streams and I have discovered
the following problem:
The code in main/streams/cast.c, specifically _php_stream_cast, creates
fopencookie() synthetic stream for streams that are not actual file
streams. Which works fine until such stream is used in include(), in
which case it ultimately arrives at zend_stream_fixup(). Which would in
turn call zend_stream_fsize() - which would do
fstat(fileno(file_handle->handle.fp), &buf) - and that would fail since
you can't get fileno for FILE* created by fopencookie.
Which ultimately means I can't use my custom streams for include(),
which is bad. Now, looking at the code, it doesn't actually need the
exact size - http streams can be included just fine - but insists on
having it if it has fp (which it can have for basically any kind of
stream due to the cookie trick). Does anyone has any idea why and if it
can be fixed?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
It looks like the only solution is define a new stream type for zend_stream that delegates stream operations to user-defined callbacks.
Moriyoshi
Hi!
I try to do some complex code with custom streams and I have discovered the following problem:
The code in main/streams/cast.c, specifically _php_stream_cast, creates fopencookie() synthetic stream for streams that are not actual file streams. Which works fine until such stream is used in include(), in which case it ultimately arrives at zend_stream_fixup(). Which would in turn call zend_stream_fsize() - which would do fstat(fileno(file_handle->handle.fp), &buf) - and that would fail since you can't get fileno for FILE* created by fopencookie.
Which ultimately means I can't use my custom streams for include(), which is bad. Now, looking at the code, it doesn't actually need the exact size - http streams can be included just fine - but insists on having it if it has fp (which it can have for basically any kind of stream due to the cookie trick). Does anyone has any idea why and if it can be fixed?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hmm, it has already supported through ZEND_HANDLE_STREAM. So then, changing the interface of fopen_function to return zend_stream instead of FILE* should be fine.
Moriyoshi
It looks like the only solution is define a new stream type for zend_stream that delegates stream operations to user-defined callbacks.
Moriyoshi
Hi!
I try to do some complex code with custom streams and I have discovered the following problem:
The code in main/streams/cast.c, specifically _php_stream_cast, creates fopencookie() synthetic stream for streams that are not actual file streams. Which works fine until such stream is used in include(), in which case it ultimately arrives at zend_stream_fixup(). Which would in turn call zend_stream_fsize() - which would do fstat(fileno(file_handle->handle.fp), &buf) - and that would fail since you can't get fileno for FILE* created by fopencookie.
Which ultimately means I can't use my custom streams for include(), which is bad. Now, looking at the code, it doesn't actually need the exact size - http streams can be included just fine - but insists on having it if it has fp (which it can have for basically any kind of stream due to the cookie trick). Does anyone has any idea why and if it can be fixed?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Fri, 04 Mar 2011 01:26:20 -0000, Stas Malyshev smalyshev@sugarcrm.com
wrote:
I try to do some complex code with custom streams and I have discovered
the following problem:The code in main/streams/cast.c, specifically _php_stream_cast, creates
fopencookie() synthetic stream for streams that are not actual file
streams. Which works fine until such stream is used in include(), in
which case it ultimately arrives at zend_stream_fixup(). Which would in
turn call zend_stream_fsize() - which would do
fstat(fileno(file_handle->handle.fp), &buf) - and that would fail since
you can't get fileno for FILE* created by fopencookie.
Which ultimately means I can't use my custom streams for include(),
which is bad. Now, looking at the code, it doesn't actually need the
exact size - http streams can be included just fine - but insists on
having it if it has fp (which it can have for basically any kind of
stream due to the cookie trick). Does anyone has any idea why and if it
can be fixed?
Can you tell what exactly you're doing? Why is there any cast in the first
place?
As far as I can see, the include should eventually call
php_stream_open_for_zend_ex, which should give a ZEND_HANDLE_STREAM file
handle that defers reading to _php_stream_read and fsize to
php_zend_stream_fsizer, with no casting involved.
--
Gustavo Lopes
Hi!
Can you tell what exactly you're doing? Why is there any cast in the first
place?As far as I can see, the include should eventually call
php_stream_open_for_zend_ex, which should give a ZEND_HANDLE_STREAM file
handle that defers reading to _php_stream_read and fsize to
php_zend_stream_fsizer, with no casting involved.
That's a regular include for file, however that one is actually a custom
stream handler. I'm not sure yet what led for it to be converted to
ZEND_HANDLE_FP, but if we're providing means to do that in the API, it
sounds logical that the API shouldn't then require ZEND_HANDLE_FP to be
pure file. I.e., if we already saying we're creating non-file FILE* in
our code, then our code should be able to process it, shouldn't it?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227