zend_stream_fixup

The idea is that the zend engine should only call the functions in
zend_stream.c to access the script input. The fixup function is
designed to promote FILE* or file descriptors up to something
compatible with its stdio stream reading functions. Filenames are
handed out to PHP and opened up using the streams layer.

The rule for the fixup function is that it either errors out, or sets
up the zend_file_handle so that zend_stream_XXX functions will work.

--Wez.

On Wed, 9 Mar 2005 12:32:54 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

Can somebody explain me what zend_stream_fixup() function does? I see that
it I give it ZEND_HANDLE_FP it converts it to ZEND_HANDLE_STREAM, but the
handle of the stream does not become php_stream *, it still is FILE *.
Does it mean that when I have ZEND_HANDLE_STREAM, the handle basically can
be both FILE * and php_stream *? How can I distinguish between these
situations?

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

WF>>_FP means that it is a plain file handle, which cannot be used with
WF>>the zend_stream functions as-is, STREAM means that the zend_stream
WF>>functions can work.

That I understand. What I do not understand is why this single function
needs it's own type. Why it can't just handle all file_handle types just
like any other functions do. I would understand if there were ten function
like this - but so far we have one.

WF>>Look, if you need to stat the damned thing, why not just add a stat
WF>>method to zend_streams.c ?

Because stat is not the only thing it is needed and because I think it's
wrong way to do things. I think the right way is for STREAM to be
php_stream and for FP to be FP.

Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

WF>>This is frustrating (and annoying). It's a simple abstraction layer
WF>>so that the zend engine can efficiently parse input from arbitrary
WF>>data sources, including, but not limited to, php streams.

OK, now we are getting somewhere. The problem is that this abstraction is
used in one (1) place over whole engine and it abstracts it so much
that leads to the situation that any extension wanting to work with
file_handle beyond single operation of read cannot do so.

WF>>If you told me exactly what you're trying to do, we can work together
WF>>more productively.

I'm trying to work with file_handle, e.g. seek it, stat it, probably
something elase in the future.

WF>>Instead, you've got some secret code that needs to do something
WF>>magical with the stream; you won't tell me what that is, and you don't

Nothing macical, just handlers implemented by php_stream, like stat and
seek. And, of course, provided by stdio.

WF>>If you would ask useful, practical questions, like "I need to be able
WF>>to stat the stream and perform operations X, Y, Z; how can we

I know how to stat the stream. The problem is that doesn't help me to stat
file_handle since I don't know if it's a stream or not. And adding a copy
of whole stream ops handler table and implementing all of these ops anew
for FILE * just because of one zend_stream_read function seems a waste of
code to me. Unless you show me the reason why zend_stream_read warrants
this additional layer of abstraction.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115