zend_stream_fixup

20 years ago by Stanislav Malyshev — view source

unread

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

20 years ago by Wez Furlong — view source

unread

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>The idea is that the zend engine should only call the functions in
WF>>zend_stream.c to access the script input. The fixup function is

But file_handle is not used only for input. There are a lof of other
things that can be done with handle. Getting stat, for example, or
seeking. It's possible to do it with FILE * and with php_stream, but not
with the result of the fixup function. Actually, after fixup function it
is impossible to do anything but read and close with the handle. I think
it's very wrong.

WF>>designed to promote FILE* or file descriptors up to something
WF>>compatible with its stdio stream reading functions. Filenames are
WF>>handed out to PHP and opened up using the streams layer.
WF>>
WF>>The rule for the fixup function is that it either errors out, or sets
WF>>up the zend_file_handle so that zend_stream_XXX functions will work.

But this means if you get a file handle which is ZEND_HANDLE_STREAM, you
cannot use it as a stream - it might be result of stream open, in which
case handle is php_stream *, or result of fixup, in which case is't FILE
*. Don't you think it's wrong?

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

20 years ago by Wez Furlong — view source

unread

What are you trying to do exactly?
The engine only needs to read from such a file handle and feed that
data into its lexer and parser.

--Wez.

On Wed, 9 Mar 2005 17:22:58 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>The idea is that the zend engine should only call the functions in
WF>>zend_stream.c to access the script input. The fixup function is

But file_handle is not used only for input. There are a lof of other
things that can be done with handle. Getting stat, for example, or
seeking. It's possible to do it with FILE * and with php_stream, but not
with the result of the fixup function. Actually, after fixup function it
is impossible to do anything but read and close with the handle. I think
it's very wrong.

WF>>designed to promote FILE* or file descriptors up to something
WF>>compatible with its stdio stream reading functions. Filenames are
WF>>handed out to PHP and opened up using the streams layer.
WF>>
WF>>The rule for the fixup function is that it either errors out, or sets
WF>>up the zend_file_handle so that zend_stream_XXX functions will work.

But this means if you get a file handle which is ZEND_HANDLE_STREAM, you
cannot use it as a stream - it might be result of stream open, in which
case handle is php_stream *, or result of fixup, in which case is't FILE
*. Don't you think it's wrong?

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>What are you trying to do exactly?

For example, I try to stat a file_handle (in case it's possible - i.e.
either it's a file or stream operator allows doing stat on it). Current
way of doing things guarantees crash on STREAM handle whatever I do,
since there's no way to know is this STREAM a FILE * (and thus one should
fstat) or php_stream * (and thus one should use stream ops). It wasn't
like this before.

WF>>The engine only needs to read from such a file handle and feed that
WF>>data into its lexer and parser.

Depends on what do you mean by "the engine". Are you claiming that there
is not and should not be any way to do anything but reading and closing
the file_handle? It certainly wasn't so before the fixup appeared.

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

20 years ago by Wez Furlong — view source

unread

Why do you need to stat it?
You can't rely on stat working.

--Wez.

On Wed, 9 Mar 2005 17:47:13 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>What are you trying to do exactly?

For example, I try to stat a file_handle (in case it's possible - i.e.
either it's a file or stream operator allows doing stat on it). Current
way of doing things guarantees crash on STREAM handle whatever I do,
since there's no way to know is this STREAM a FILE * (and thus one should
fstat) or php_stream * (and thus one should use stream ops). It wasn't
like this before.

WF>>The engine only needs to read from such a file handle and feed that
WF>>data into its lexer and parser.

Depends on what do you mean by "the engine". Are you claiming that there
is not and should not be any way to do anything but reading and closing
the file_handle? It certainly wasn't so before the fixup appeared.

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>You can't rely on stat working.

Why not? What's so special in stat that it can not work on file handle?

And why this STREAM type at all - if the only places it is used is where
you have switch on type anyway or in zend_stream.c where you could have
the switch as well? What did you achive by this but breaking all code that
used file_handle for more that read/close? So far I see that by using
fixup and converting all FPs to STREAMs you saved one if in
zend_stream_read/zend_stream_getc and that's it. Is there anything I miss?

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

20 years ago by Wez Furlong — view source

unread

Yes, you missed that a stream can be any stream from PHP land.

Which code in the engine does more than read/close?

--Wez.

On Wed, 9 Mar 2005 18:00:11 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>You can't rely on stat working.

Why not? What's so special in stat that it can not work on file handle?

And why this STREAM type at all - if the only places it is used is where
you have switch on type anyway or in zend_stream.c where you could have
the switch as well? What did you achive by this but breaking all code that
used file_handle for more that read/close? So far I see that by using
fixup and converting all FPs to STREAMs you saved one if in
zend_stream_read/zend_stream_getc and that's it. Is there anything I miss?

20 years ago by Stanislav Malyshev — view source

unread

WF>>Yes, you missed that a stream can be any stream from PHP land.

If it's the PHP stream that's ok for it to be STREAM. PHP streams have own
operators for foing things, so if I know STREAM type refers to PHP stream
it is completely OK.
What I do not understand is why you convert FP to STREAM. Only value from
this conversion I can see is that zend_stream_read/zend_stream_getc now call
reader instead of doing if and then calling either reader for stream or
file-reading function of the engine (which, btw, is private to the engine
so you even can not call or set it from outside - meaning it could be as
well inlined directly in zend_stream_read/zend_stream_getc - and
these seem to be the only functions that use the reader anyway).

WF>>Which code in the engine does more than read/close?

My code. Since handlers using file_handle (e.g. compile_file handler) is
overridable, any code can be in these handlers. And what I want is some
sane rules about what can be in file_handle. Limiting file_handle to
read/close only doesn't seem reasonable to me, especially that it wasn't
so for a long time and only reason so far I see for it is saving two ifs -
and underlying file protocols (either fd or FILE * or PHP stream) allow
much more than just reading and closing.

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

20 years ago by Wez Furlong — view source

unread

Bitching about code breakage for something that is not in public CVS
isn't going to win you any points.

This code was added specifically so that include and require will
operate correctly on all php streams. Not only that, but it has been
there for quite a long time now; you've had plenty of time to raise
issues.

If you need to call stat from within the engine, it can be added, but
you need to be aware that stat will not work in all cases, and the
fact that no other place in the engine needed it at the time it was
written explains why there is no stat prototype.

The purpose of the stream structure is not to save ifs, it's to allow
the engine to call into the php streams layer without a hard
dependency on PHP, which is something you guys have been touchy about
in the past.

--Wez.

On Wed, 9 Mar 2005 18:22:45 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>Yes, you missed that a stream can be any stream from PHP land.

If it's the PHP stream that's ok for it to be STREAM. PHP streams have own
operators for foing things, so if I know STREAM type refers to PHP stream
it is completely OK.
What I do not understand is why you convert FP to STREAM. Only value from
this conversion I can see is that zend_stream_read/zend_stream_getc now call
reader instead of doing if and then calling either reader for stream or
file-reading function of the engine (which, btw, is private to the engine
so you even can not call or set it from outside - meaning it could be as
well inlined directly in zend_stream_read/zend_stream_getc - and
these seem to be the only functions that use the reader anyway).

WF>>Which code in the engine does more than read/close?

My code. Since handlers using file_handle (e.g. compile_file handler) is
overridable, any code can be in these handlers. And what I want is some
sane rules about what can be in file_handle. Limiting file_handle to
read/close only doesn't seem reasonable to me, especially that it wasn't
so for a long time and only reason so far I see for it is saving two ifs -
and underlying file protocols (either fd or FILE * or PHP stream) allow
much more than just reading and closing.

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>Bitching about code breakage for something that is not in public CVS
WF>>isn't going to win you any points.

Calling discussion about code "bitching" is not going to win you any
points either. I do not see why code that is not in public CVS is worse
than code that is or how breaking it is nicer than breaking code that is.
I'm pretty sure I probably could find public code that would be broken by
that too - I know a number of public code modules doing more or less the
same my code does - I just don't see why it would matter even a
slightest bit.

WF>>This code was added specifically so that include and require will
WF>>operate correctly on all php streams. Not only that, but it has been

Can you please explain how converting FP to STREAM in fixup helps
include/require? I don't see any benefit there.

WF>>there for quite a long time now; you've had plenty of time to raise
WF>>issues.

That's one hell of an argument. If I didn't notice it was broken before,
then it stops being broken now? Try this with bug reports: "this bug was
in PHP for so long, you had a lot of time to raise issues but you didn't,
so we list it as a feature". Nice, eh? So please let's discuss it to the
matter.

WF>>If you need to call stat from within the engine, it can be added, but
WF>>you need to be aware that stat will not work in all cases, and the
WF>>fact that no other place in the engine needed it at the time it was
WF>>written explains why there is no stat prototype.

Once again. I do not say there should be stat. I say "FP should not
be converted to STREAM". That's it. Nothing more. I'm not against having
STREAM type. I'm not against having FP type. I'm not agains having
file_handle. Only thing I'm against is to have fixup function convert FP
to STREAM and thus having STREAM mean "something you can just read and
close" instead of "php_stream that you can read and close if you don't
want to know about php_stream but if you want, you can do whatever
php_stream can".

WF>>The purpose of the stream structure is not to save ifs, it's to allow
WF>>the engine to call into the php streams layer without a hard
WF>>dependency on PHP, which is something you guys have been touchy about
WF>>in the past.

But how converting FP to stream helps that? FP is not more PHP-dependant
than STREAM. Only code for which this conversion matters - as far as I see
now and you didn't yet brought any example on the contrary, it you have
ones please bring them forth as I really want to see them - the only such
code so far is zend_stream_read. zend_stream_read is perfectly capable of
handling both FP and STREAM with very minimal effort - so what exactly is
the benefit of converting FP to STREAM?

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

20 years ago by Derick Rethans — view source

unread

WF>>there for quite a long time now; you've had plenty of time to raise
WF>>issues.

That's one hell of an argument. If I didn't notice it was broken before,
then it stops being broken now? Try this with bug reports: "this bug was
in PHP for so long, you had a lot of time to raise issues but you didn't,
so we list it as a feature". Nice, eh? So please let's discuss it to the
matter.

But that's exactly what happens, otherwise we break BC.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

20 years ago by Stanislav Malyshev — view source

unread

DR>>> so we list it as a feature". Nice, eh? So please let's discuss it to the
DR>>> matter.
DR>>
DR>>But that's exactly what happens, otherwise we break BC.

BC is very important, but in this case it's irrelevant unless we have some
functions beside zend_stream_read that expect file_handle to be STREAM
only and the user can override these. So far I do not know about any of
such functions (and yes, I checked in the code). That's why I ask Wez if I
missed something - are there such functions? If not, removing FP to STREAM
conversion (and fixing zend_stream_read) would not break anything and thus
BC would be preserved.

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

20 years ago by Marcus Boerger — view source

unread

Hello Stanislav,

Wednesday, March 9, 2005, 6:23:01 PM, you wrote:

DR>>>> so we list it as a feature". Nice, eh? So please let's discuss it to the
DR>>>> matter.
DR>>>
DR>>>But that's exactly what happens, otherwise we break BC.

BC is very important, but in this case it's irrelevant unless we have some
functions beside zend_stream_read that expect file_handle to be STREAM
only and the user can override these. So far I do not know about any of
such functions (and yes, I checked in the code). That's why I ask Wez if I
missed something - are there such functions? If not, removing FP to STREAM
conversion (and fixing zend_stream_read) would not break anything and thus
BC would be preserved.

There are and there were several plans to use the stream nature. Those plans
were partly public when Wez did the whole streams infrastructure. Renabling
pure fp's now will now break any external extension that relies on that
fact. And thus we must not change anything because of any other unknown
extension.

Best regards,
Marcus mailto:mail@marcus-boerger.de

20 years ago by Stanislav Malyshev — view source

unread

MB>>were partly public when Wez did the whole streams infrastructure.
MB>>Renabling pure fp's now will now break any external extension that
MB>>relies on that fact. And thus we must not change anything because of
MB>>any other unknown extension.

Do you know any external extension that relies on the fact that
file_handle is only STREAM - taking into account this is false -
file-handle can perfectly well be anything else prior to calling fixup -
and probably after too, since dtor does have switch? Can you explain me
why this extension supposes that and why it doesn't handle any other types
of handles?

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

20 years ago by Stanislav Malyshev — view source

unread

SM>>Do you know any external extension that relies on the fact that
SM>>file_handle is only STREAM - taking into account this is false -
SM>>file-handle can perfectly well be anything else prior to calling fixup
SM>>- and probably after too, since dtor does have switch? Can you explain

BTW, after more look on the code - NOTHING guarantees you the handle is
STREAM after the fixup, since fixup calls zend_stream_open, and
zend_stream_open calls zend_stream_open_function which is overridable and
can set file_handle to anything - and only FP would be converted to
STREAM, but all others typed would not. So actually if anybody overrides
zend_stream_open_function so that it returns anything but STREAM or FP
(and there's no indication anywhere why such behaviour would not be
acceptable) - the extension that supposes handles can be only STREAM even
after fixup is broken. Only thing fixup is guaranteeing that the handle is
never FP - which I don't see to be a reasonble thing anyway, why FP is so
special that there's a dedicated function to kill it?

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

20 years ago by Wez Furlong — view source

unread

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

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

I can't believe that this thread has escalated like this.

--Wez.

On Thu, 10 Mar 2005 16:26:39 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

MB>>For a short idea, we could implement something like jar's possible
MB>>named par as in php archive :-)

What I don't understand is how this is connected to promoting FP to
STREAM. Won't it be implemented via PHP streams anyway?

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

20 years ago by Stanislav Malyshev — view source

unread

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

20 years ago by Wez Furlong — view source

unread

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.

You have all the different things that php streams provides as well,
which is why those functions exist.

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.

Right, and that causes the ZE to have a circular dep on PHP, which is
something that Zend didn't want in the past.

--Wez.

20 years ago by Stanislav Malyshev — view source

unread

WF>>> needs it's own type. Why it can't just handle all file_handle types just
WF>>> like any other functions do. I would understand if there were ten function
WF>>> like this - but so far we have one.
WF>>
WF>>You have all the different things that php streams provides as well,
WF>>which is why those functions exist.

No, you have not! That's whole point - you can not use STREAM handle as
PHP stream, because handle there may be FILE * or php_stream * - and you
have no way to know which it is!

WF>>Right, and that causes the ZE to have a circular dep on PHP, which is
WF>>something that Zend didn't want in the past.

How is that? I don't see any dependency on PHP that converting FP to
STREAM removes. Explain me, if I remove that conversion and put instead
an if into zend_stream_read that would do the same thing - how it
suddently would become dependant on PHP?

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

20 years ago by Wez Furlong — view source

unread

http://viewcvs.php.net/viewcvs.cgi/php-src/main/main.c.diff?r1=1.526&r2=1.527

On Thu, 10 Mar 2005 20:15:55 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>> needs it's own type. Why it can't just handle all file_handle types just
WF>>> like any other functions do. I would understand if there were ten function
WF>>> like this - but so far we have one.
WF>>
WF>>You have all the different things that php streams provides as well,
WF>>which is why those functions exist.

No, you have not! That's whole point - you can not use STREAM handle as
PHP stream, because handle there may be FILE * or php_stream * - and you
have no way to know which it is!

WF>>Right, and that causes the ZE to have a circular dep on PHP, which is
WF>>something that Zend didn't want in the past.

How is that? I don't see any dependency on PHP that converting FP to
STREAM removes. Explain me, if I remove that conversion and put instead
an if into zend_stream_read that would do the same thing - how it
suddently would become dependant on PHP?

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>http://viewcvs.php.net/viewcvs.cgi/php-src/main/main.c.diff?r1=1.526&r2=1.527

And? What this is supposed to explain? My questions are still unanswered.
I still do not see how converting FP to STREAm helps anything. This patch
has nothing to do with that - it deals with php_stream that I have no any
problem with.

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

20 years ago by Wez Furlong — view source

unread

The point is that you associate the approprite methods with the file
handle at the time you set it to STREAM.

--Wez.

On Fri, 11 Mar 2005 21:18:37 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>http://viewcvs.php.net/viewcvs.cgi/php-src/main/main.c.diff?r1=1.526&r2=1.527

And? What this is supposed to explain? My questions are still unanswered.
I still do not see how converting FP to STREAm helps anything. This patch
has nothing to do with that - it deals with php_stream that I have no any
problem with.

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

20 years ago by Stanislav Malyshev — view source

unread

WF>>The point is that you associate the approprite methods with the file
WF>>handle at the time you set it to STREAM.

I think we started to go in circles or you not paying attention what I
actually ask. Once more: I KNOW and I UNDERSTAND why you have these two
handlers for streams (php_stream ). I do not understand why do you use
the same thing for FPs (once more for FILE , not for php_stream *!) -
provided that the only function that actually benefits from it is
zend_stream_read and it is not overridable.

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

20 years ago by Wez Furlong — view source

unread

On Sun, 13 Mar 2005 11:10:20 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>The point is that you associate the approprite methods with the file
WF>>handle at the time you set it to STREAM.

I think we started to go in circles or you not paying attention what I
actually ask. Once more: I KNOW and I UNDERSTAND why you have these two
handlers for streams (php_stream *). I do not understand why do you use
the same thing for FPs (once more for FILE *, not for php_stream *!) -
provided that the only function that actually benefits from it is
zend_stream_read and it is not overridable.

Read the code again; the read function is assigned along with the type
and pointer.

--Wez.

20 years ago by Wez Furlong — view source

unread

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

If you told me exactly what you're trying to do, we can work together
more productively.
Instead, you've got some secret code that needs to do something
magical with the stream; you won't tell me what that is, and you don't
seem to understand that the code is the way it is, for abstraction
purposes.

If you would ask useful, practical questions, like "I need to be able
to stat the stream and perform operations X, Y, Z; how can we
implement that?", then I can help.
It's a waste of time otherwise.

--Wez.

On Sun, 13 Mar 2005 17:13:04 +0200 (IST), Stanislav Malyshev
stas@zend.com wrote:

WF>>> handlers for streams (php_stream *). I do not understand why do you use
WF>>> the same thing for FPs (once more for FILE *, not for php_stream *!) -
WF>>> provided that the only function that actually benefits from it is
WF>>> zend_stream_read and it is not overridable.
WF>>
WF>>Read the code again; the read function is assigned along with the type
WF>>and pointer.

OK. I know it and I said twice I know it. This still does not answer my
question: why FP is converted to STREAM and is read via handler if you could
read it just fine via FP and only place where you need the handler is
zend_stream_read?

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

20 years ago by Stanislav Malyshev — view source

unread

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

Depends on what do you mean by "the engine". Are you claiming that there is not and should not be any way to do anything but reading and closing the file_handle? It certainly wasn't so before the fixup appeared.

Depends on what do you mean by "the engine". Are you claiming that there is not and should not be any way to do anything but reading and closing the file_handle? It certainly wasn't so before the fixup appeared.

What I don't understand is how this is connected to promoting FP to STREAM. Won't it be implemented via PHP streams anyway?

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.

And? What this is supposed to explain? My questions are still unanswered. I still do not see how converting FP to STREAm helps anything. This patch has nothing to do with that - it deals with php_stream that I have no any problem with.

And? What this is supposed to explain? My questions are still unanswered. I still do not see how converting FP to STREAm helps anything. This patch has nothing to do with that - it deals with php_stream that I have no any problem with.

Depends on what do you mean by "the engine". Are you claiming that there
is not and should not be any way to do anything but reading and closing
the file_handle? It certainly wasn't so before the fixup appeared.

Depends on what do you mean by "the engine". Are you claiming that there
is not and should not be any way to do anything but reading and closing
the file_handle? It certainly wasn't so before the fixup appeared.

What I don't understand is how this is connected to promoting FP to
STREAM. Won't it be implemented via PHP streams anyway?

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.

And? What this is supposed to explain? My questions are still unanswered.
I still do not see how converting FP to STREAm helps anything. This patch
has nothing to do with that - it deals with php_stream that I have no any
problem with.

And? What this is supposed to explain? My questions are still unanswered.
I still do not see how converting FP to STREAm helps anything. This patch
has nothing to do with that - it deals with php_stream that I have no any
problem with.