# streams problem in 5.3 - Thread: https://externals.io/message/51565 - Original archive: https://news-web.php.net/php.internals/51565 - Started by Stas Malyshev on 2011-03-04T01:26:20+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #51565 — Stas Malyshev — 2011-03-04T01:26:20+00:00 URL: https://externals.io/message/51565#51565 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 --- ## #51568 — Moriyoshi Koizumi — 2011-03-04T18:05:57+00:00 URL: https://externals.io/message/51565#51568 · In reply to: #51565 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 --- ## #51569 — Moriyoshi Koizumi — 2011-03-04T18:12:22+00:00 URL: https://externals.io/message/51565#51569 · In reply to: #51568 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 > > > > > […] --- ## #51570 — Gustavo Lopes — 2011-03-04T18:48:04+00:00 URL: https://externals.io/message/51565#51570 · In reply to: #51565 On Fri, 04 Mar 2011 01:26:20 -0000, Stas Malyshev 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 --- ## #51580 — Stas Malyshev — 2011-03-06T23:46:44+00:00 URL: https://externals.io/message/51565#51580 · In reply to: #51570 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