# zend_stream_fixup - Thread: https://externals.io/message/15319 - Original archive: https://news-web.php.net/php.internals/15319 - Started by Stanislav Malyshev on 2005-03-09T10:32:54+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/15319.md?page=2 - 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 --- ## #15319 — Stanislav Malyshev — 2005-03-09T10:32:54+00:00 URL: https://externals.io/message/15319#15319 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 --- ## #15321 — Wez Furlong — 2005-03-09T15:18:17+00:00 URL: https://externals.io/message/15319#15321 · In reply to: #15319 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 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 --- ## #15323 — Stanislav Malyshev — 2005-03-09T15:22:58+00:00 URL: https://externals.io/message/15319#15323 · In reply to: #15321 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 --- ## #15324 — Wez Furlong — 2005-03-09T15:31:00+00:00 URL: https://externals.io/message/15319#15324 · In reply to: #15323 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 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 --- ## #15325 — Stanislav Malyshev — 2005-03-09T15:47:13+00:00 URL: https://externals.io/message/15319#15325 · In reply to: #15324 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 --- ## #15326 — Wez Furlong — 2005-03-09T15:50:43+00:00 URL: https://externals.io/message/15319#15326 · In reply to: #15325 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 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 --- ## #15327 — Stanislav Malyshev — 2005-03-09T16:00:11+00:00 URL: https://externals.io/message/15319#15327 · In reply to: #15326 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 --- ## #15328 — Wez Furlong — 2005-03-09T16:14:22+00:00 URL: https://externals.io/message/15319#15328 · In reply to: #15327 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 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? --- ## #15329 — Stanislav Malyshev — 2005-03-09T16:22:45+00:00 URL: https://externals.io/message/15319#15329 · In reply to: #15328 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 --- ## #15330 — Wez Furlong — 2005-03-09T16:53:43+00:00 URL: https://externals.io/message/15319#15330 · In reply to: #15329 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 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 --- ## #15331 — Stanislav Malyshev — 2005-03-09T17:09:41+00:00 URL: https://externals.io/message/15319#15331 · In reply to: #15330 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 --- ## #15332 — Derick Rethans — 2005-03-09T17:20:04+00:00 URL: https://externals.io/message/15319#15332 · In reply to: #15331 > 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 --- ## #15333 — Stanislav Malyshev — 2005-03-09T17:23:01+00:00 URL: https://externals.io/message/15319#15333 · In reply to: #15332 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 --- ## #15334 — Marcus Boerger — 2005-03-09T17:35:15+00:00 URL: https://externals.io/message/15319#15334 · In reply to: #15333 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 --- ## #15335 — Stanislav Malyshev — 2005-03-09T17:43:02+00:00 URL: https://externals.io/message/15319#15335 · In reply to: #15334 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 --- ## #15336 — Stanislav Malyshev — 2005-03-09T17:51:44+00:00 URL: https://externals.io/message/15319#15336 · In reply to: #15335 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 --- ## #15353 — Wez Furlong — 2005-03-10T15:58:25+00:00 URL: https://externals.io/message/15319#15353 _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 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 --- ## #15357 — Stanislav Malyshev — 2005-03-10T17:59:58+00:00 URL: https://externals.io/message/15319#15357 · In reply to: #15353 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 --- ## #15358 — Wez Furlong — 2005-03-10T18:12:29+00:00 URL: https://externals.io/message/15319#15358 · In reply to: #15357 > 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. --- ## #15359 — Stanislav Malyshev — 2005-03-10T18:15:55+00:00 URL: https://externals.io/message/15319#15359 · In reply to: #15358 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 --- ## #15361 — Wez Furlong — 2005-03-10T20:43:48+00:00 URL: https://externals.io/message/15319#15361 · In reply to: #15359 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 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 --- ## #15374 — Stanislav Malyshev — 2005-03-11T19:18:37+00:00 URL: https://externals.io/message/15319#15374 · In reply to: #15361 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 --- ## #15378 — Wez Furlong — 2005-03-11T20:29:31+00:00 URL: https://externals.io/message/15319#15378 · In reply to: #15374 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 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 --- ## #15415 — Stanislav Malyshev — 2005-03-13T09:10:20+00:00 URL: https://externals.io/message/15319#15415 · In reply to: #15378 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 --- ## #15416 — Wez Furlong — 2005-03-13T15:01:31+00:00 URL: https://externals.io/message/15319#15416 · In reply to: #15415 On Sun, 13 Mar 2005 11:10:20 +0200 (IST), Stanislav Malyshev 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. --- Next page: https://externals.io/message/15319.md?page=2