Critical bugs to fix before ANY release View as Markdown

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=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
...

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

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 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/

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

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

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