# Critical bugs to fix before ANY release - Thread: https://externals.io/message/40309 - Original archive: https://news-web.php.net/php.internals/40309 - Started by Jani Taskinen on 2008-09-07T11:33:23+00:00 - Messages: 12 - 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 --- ## #40309 — Jani Taskinen — 2008-09-07T11:33:23+00:00 URL: https://externals.io/message/40309#40309 There are some bugs that have to be fixed before any actual release can be even dreamed of: http://bugs.php.net/search.php?cmd=display&status=Critical Note that 2 of those even have patches attached to fix them.. --Jani --- ## #40331 — Lars Strojny — 2008-09-08T10:13:31+00:00 URL: https://externals.io/message/40309#40331 · In reply to: #40309 Hi Jani, Am Sonntag, den 07.09.2008, 14:33 +0300 schrieb Jani Taskinen: > There are some bugs that have to be fixed before any actual release can be even > dreamed of: http://bugs.php.net/search.php?cmd=display&status=Critical > > Note that 2 of those even have patches attached to fix them.. Checked #27792: I don't like the introduction of a number of if (ret > LONG_MAX) ... else ... Any reason not doing that in RETURN_LONG() or alternatively introducing a RETURN_BIGINT() or something like that? cu, Lars --- ## #40335 — Pierre Joye — 2008-09-08T10:56:16+00:00 URL: https://externals.io/message/40309#40335 · In reply to: #40331 hi Lars, > Hi Jani, > > Am Sonntag, den 07.09.2008, 14:33 +0300 schrieb Jani Taskinen: > > […] > > Checked #27792: I don't like the introduction of a number of > > if (ret > LONG_MAX) > ... > else > ... > or alternatively introducing > a RETURN_BIGINT() or something like that? Large integer and large file support are planed for php6. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #40340 — Jani Taskinen — 2008-09-08T13:13:22+00:00 URL: https://externals.io/message/40309#40340 · In reply to: #40335 Pierre Joye wrote: > hi Lars, > > > > […] > > > […] > > Large integer and large file support are planed for php6. And who decided that? The patches exist, what's preventing us from adding this long overdue support (originally planned for 5.1!!!) ?? --Jani --- ## #40341 — Pierre Joye — 2008-09-08T13:16:17+00:00 URL: https://externals.io/message/40309#40341 · In reply to: #40340 > > […] > > And who decided that? The patches exist, what's preventing us from adding > this long overdue support (originally planned for 5.1!!!) ?? The patches do not exist, large integer is not implemented and LFS is partially implemented. And who decided that? The various free time available between releases, and we just missed 5.3. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #40343 — Christian Schneider — 2008-09-08T13:30:01+00:00 URL: https://externals.io/message/40309#40343 · In reply to: #40309 Jani Taskinen wrote: > There are some bugs that have to be fixed before any actual release can > be even dreamed of: > http://bugs.php.net/search.php?cmd=display&status=Critical > > Note that 2 of those even have patches attached to fix them.. I had a quick look at bug http://bugs.php.net/bug.php?id=45928 and found the problem to be in Zend/zend_stream.c function zend_stream_fsize(): It uses `fstat()` to determine the filesize which on MacOS X for pipes returns either 0 (my interpretation: no data from the pipe ready yet) or a number up to 16384 (my interpretation: data from the pipe ready but the maximum buffer size is 16k). I see several solutions but I'm not sure which is the desired one: - return 0 (size unknown) if the file is a pipe (or socket, ...) - return 0 if the file is not a regular file (or symlink, dir?) - look into a way of determining EOF reached As a quick test I changed return buf.st_size; in function zend_stream_fsize() to return 0; and cat 30k.php | php worked after that. - Chris --- ## #40345 — Alexey Zakhlestin — 2008-09-08T14:39:48+00:00 URL: https://externals.io/message/40309#40345 · In reply to: #40343 On Mon, Sep 8, 2008 at 5:30 PM, Christian Schneider wrote: > I had a quick look at bug > http://bugs.php.net/bug.php?id=45928 > and found the problem to be in Zend/zend_stream.c function > zend_stream_fsize(): It uses `fstat()` to determine the filesize which on > MacOS X for pipes returns either 0 (my interpretation: no data from the > pipe ready yet) or a number up to 16384 (my interpretation: data from > the pipe ready but the maximum buffer size is 16k). I believe your interpretation is correct. it returns amount of data, which is available on pipe, so we can request that amount immediately, and later check if some more is available. > I see several solutions but I'm not sure which is the desired one: > - return 0 (size unknown) if the file is a pipe (or socket, ...) > - return 0 if the file is not a regular file (or symlink, dir?) > - look into a way of determining EOF reached well, I guess there is no way to get "filesize" of piped data, because it is completely dynamic. at the lowest level, libc's read() returns 0 in case of EOF and -1 in case of error. that's the way to distinguish them. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #40954 — Lukas Kahwe Smith — 2008-10-13T18:30:54+00:00 URL: https://externals.io/message/40309#40954 · In reply to: #40309 > There are some bugs that have to be fixed before any actual release > can be even dreamed of: http://bugs.php.net/search.php?cmd=display&status=Critical > > Note that 2 of those even have patches attached to fix them.. There are 2 left at this point: 1) http://bugs.php.net/bug.php?id=27792 I know we have been talking about LFS since ages (just as we have been talking about expanding the storage limit for integers). But I would not consider this a bug let alone critical. Its a missing feature, that we all agree should be provided. However I do not see why this is critical for PHP 5.3 .. or am I missing something 2) http://bugs.php.net/bug.php?id=44936 Last comment was on September 8th, where Stas asked what the exact BC issue was .. I imagine the issue is that this causes issues in situation where the value is being compared to some non PHP source (like a configuration file). regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40959 — Stanislav Malyshev — 2008-10-13T23:04:29+00:00 URL: https://externals.io/message/40309#40959 · In reply to: #40954 Hi! > 2) http://bugs.php.net/bug.php?id=44936 > > Last comment was on September 8th, where Stas asked what the exact BC > issue was .. I imagine the issue is that this causes issues in situation > where the value is being compared to some non PHP source (like a > configuration file). It looks rather strange to me that bug labeled as "critical" doesn't get any feedback for a month. I'll move it to feedback status. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40962 — Stanislav Malyshev — 2008-10-14T00:38:47+00:00 URL: https://externals.io/message/40309#40962 · In reply to: #40954 Hi! > There are 2 left at this point: I think we may want also to look at: http://bugs.php.net/bug.php?id=42862 and there was some ziplib directories issue that I'm not sure if it was addressed. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #40996 — johannes@php.net — 2008-10-14T14:06:11+00:00 URL: https://externals.io/message/40309#40996 · In reply to: #40954 > 1) http://bugs.php.net/bug.php?id=27792 > > I know we have been talking about LFS since ages (just as we have been > talking about expanding the storage limit for integers). But I would > not consider this a bug let alone critical. Its a missing feature, > that we all agree should be provided. However I do not see why this is > critical for PHP 5.3 .. or am I missing something Yes. And usually it's quite easy fixed when using a 64bit build and as we're going to have 64bit Windows builds it shouldn't be a problem for anybody really needing that functionality. The last time it was discussed it was said we can't easily turn it on globally as it would interfere with "small" stat pointer received by Apache and others, nobody proposed a patch and I doubt anybody will... Correct me when wrong: It would have been critical some one or two years ago, nowadays 64bit systems are available and used enough. johannes --- ## #40999 — sean finney — 2008-10-14T16:44:51+00:00 URL: https://externals.io/message/40309#40999 · In reply to: #40996 hi, (wow, de-lurking twice in one day!) > The last time it was discussed it was said we can't easily turn it on > globally as it would interfere with "small" stat pointer received by > Apache and others, nobody proposed a patch and I doubt anybody will... i think you're right: apache (specifically, libapr, i believe) passes stat structs to/from the loaded modules, and thus needs to be built with the same LFS flags, otherwise you will not have a happy server. i believe the only other LFS related issue is with zlib which uses a long somewhere that should have been an off_t iirc. in debian we enabled and subsequently disabled LFS support a couple times while we worked this out (it's enabled >= etch). fwiw enabling the support is a matter of passing an extra couple compile flags at ./configure time, so it's not like a user compiling php from source is challenged to do this if they have already compiled apache with the proper flags... > Correct me when wrong: It would have been critical some one or two years > ago, nowadays 64bit systems are available and used enough. i think most maintstream distributions have already patched php to have LFS suppport (redhat/fedora/debian/ubuntu/gentoo, from my knowledge though i could be wrong on the non .deb distros). however, they have a slightly easier situation for doing this, as they also provide the other utilities (apache, zlib, etc), so they can ensure everything is compiled properly. i think for php.net you may be in a more difficult position because you don't control the distribution of the whole stack, so the best that you could do is to detect the compile settings of the other components, and incorporate them as CFLAGS at ./configure-time. sean