Hi,
can anyone shed a light on what zend_stream_fixup (in zend_stream.c) is for?
>From what I get from the code, it seems it ensures that the whole file
is read into memory, no matter what type the zend_file_handle is...
Thanks!
Greetings
Nico
--
PHP Internals - PHP Runtime Development Maili
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) p
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
On Sun, 13 Mar 2005 11:10:20 +0200 (IST), Stanislav Malyshev
<[EMAIL PROTECTED]> 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 as
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 *).
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
<[EMAIL PROTECTED]> wrote:
> WF>>http://viewcvs.php.net/viewcvs.cgi/php-src/main/main.c.diff?r1=1.526&r2=1.527
>
> An
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
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
<[EMAIL PROTECTED]> 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 under
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 th
> 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
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_han
_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
MB>>> What I don't understand is how this is connected to promoting FP to
MB>>> STREAM. Won't it be implemented via PHP streams anyway?
MB>>
MB>>If we can garantee that the FP's won't interfere it won't be a problem.
MB>>But can we? If we can i'll shut up :-)
I don't see even what's here to guara
Hello Stanislav,
Thursday, March 10, 2005, 3:26:39 PM, you 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
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
[EMAIL PROTECTED
Hello Zeev,
Thursday, March 10, 2005, 3:12:36 PM, you wrote:
> At 18:14 09/03/2005, Wez Furlong wrote:
>>Yes, you missed that a stream can be any stream from PHP land.
>>
>>Which code in the engine does more than read/close?
> Wez,
> I think it's beyond looking into which code in the engine doe
At 18:14 09/03/2005, Wez Furlong wrote:
Yes, you missed that a stream can be any stream from PHP land.
Which code in the engine does more than read/close?
Wez,
I think it's beyond looking into which code in the engine does more than
read/close right now. It has to do with having infrastructure co
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, afte
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
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 h
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
On Wed, 9 Mar 2005, Stanislav Malyshev wrote:
> 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
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
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
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. O
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
<[EMAIL PROTECTED]> wrote:
> WF>>You can't rely on stat working.
>
> Why not? What's so special in stat that it c
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
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
<[EMAIL PROTECTED]> 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 s
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
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
<[EMAIL PROTECTED]> wrote:
> WF>>The idea is that the zend engine should only call the function
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 possib
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
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
33 matches
Mail list logo
