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
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=CriticalNote 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
hi Lars,
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=CriticalNote 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
...
or alternatively introducing
a RETURN_BIGINT() or something like that?
Large integer and large file support are planed for php6.
Cheers,
Pierre
Pierre Joye wrote:
hi Lars,
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=CriticalNote that 2 of those even have patches attached to fix them..
Checked #27792: I don't like the introduction of a number ofif (ret > LONG_MAX)
...
else
...or alternatively introducing
a RETURN_BIGINT() or something like that?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
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!!!) ??
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
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=CriticalNote 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
On Mon, Sep 8, 2008 at 5:30 PM, Christian Schneider
cschneid@cschneid.com 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 usesfstat()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/
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=CriticalNote that 2 of those even have patches attached to fix them..
There are 2 left at this point:
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
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
Hi!
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
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
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
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