# towards 5.3 alpha1

- Thread: https://externals.io/message/39349
- Original archive: https://news-web.php.net/php.internals/39349
- Started by johannes@php.net on 2008-07-26T11:02:26+00:00
- Messages: 7
- 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

---

## #39349 — johannes@php.net — 2008-07-26T11:02:26+00:00

URL: https://externals.io/message/39349#39349

Hello all,

As some of you may have noticed the 5.3 todo list [1] has been  
reworked a bit. There is now a list for alpha1 and some more items for  
alpha2. As previously announced Lukas and I are allowing low risk  
self contained work to continue until alpha2 on a case by case basis.

However there are even still a few items that did not make it in for  
the alpha1 feature freeze that we have permitted to be worked on over  
the course of this weekend. Or just general bug fixing items we need  
to have done before alpha1 release (planned for July 31st):
1) various string optimization patches from Matt (Scott)
2) various ZE optimization patches from Matt (Dmitry)
3) add tests for fileinfo (note fileinfo is now bundled and enabled by  
   default just as mimemagic was before PHP 5.2) (Derick)
4) add openssl_parse_csr (Pierre)
5) "OpenLDAP C API cleanup patch" and pat44 "LDAP control
   support" (Pierre)
6) Zend Signal Handling (Dmitry)
7) add array_replace[_recursive] (diff, phpt) (Johannes)
8) prepare windows build infrastructure (Pierre, Rob, Liz)
9) make parent::/self:: forwarding (Dmitry)
10) make ming compile with libming 0.3 and up (Frank)
11) unix path separators in spl (Marcus)
12) add Christians Reflection patch for closures (Marcus)

@Marcus: Can you handle 11) and 12)?

Let us know if we are missing anything from this list ASAP!

Then a couple questions that need to be answered and quickly resolved:
- undeprecate ticks: as long as we have no replacement for the signal
  handling we shouldn't deprecate the only way to do that.
- drop __toString() from Closures
- Do not include 3xx http codes in the fopen wrapper

Again a general request to the developer and user community at large:
Please concentrate on finding&fixing bugs instead of functional changes
(including arginfo and parameter_parsing) and to make sure we have all
changes covered in the wiki [2] so they can be added to release notes
and the documentation. 

Lukas and Johannes

[1] http://wiki.php.net/todo/php53
[2] http://wiki.php.net/doc/scratchpad/upgrade/53

---

## #39350 — Lukas Kahwe Smith — 2008-07-26T11:57:45+00:00

URL: https://externals.io/message/39349#39350 · In reply to: #39349

> Again a general request to the developer and user community at large:
> Please concentrate on finding&fixing bugs instead of functional  
> changes
> (including arginfo and parameter_parsing) and to make sure we have all
> changes covered in the wiki [2] so they can be added to release notes
> and the documentation.


Speaking of which, just going through the open 5.3 bugs that have not  
been assigned to a developer I see the following ones as looking to be  
important to be dealt with:
http://bugs.php.net/bug.php?id=45044 (relative paths not resolved  
correctly)
http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection  
timing issue)
http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in  
parse error with no trailing newline)
http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and  
memory_limit)
http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/ 
end with underscore)
http://bugs.php.net/bug.php?id=45288 (set_include_path() functionality  
broken)
http://bugs.php.net/bug.php?id=45608 (closures don't work in static  
methods)

The rest are either assigned or PDO bugs (again, we really really  
really need someone that looks after PDO).

Of course there are also still tons of open 5.2 bugs [1] :(

regards,
Lukas Kahwe Smith
smith@pooteeweet.org

[1] http://bugs.php.net/search.php?cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bug_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begin=0

---

## #39351 — Arnaud Le Blanc — 2008-07-26T13:21:03+00:00

URL: https://externals.io/message/39349#39351 · In reply to: #39350

On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
> 
> 
> 
> > […]
> 
> 
> Speaking of which, just going through the open 5.3 bugs that have not  
> been assigned to a developer I see the following ones as looking to be  
> important to be dealt with:
> http://bugs.php.net/bug.php?id=45044 (relative paths not resolved  
> correctly)
> http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection  
> timing issue)
> http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in  
> parse error with no trailing newline)
> http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and  
> memory_limit)
> http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/ 
> end with underscore)
> http://bugs.php.net/bug.php?id=45288 (set_include_path() functionality  
> broken)
> http://bugs.php.net/bug.php?id=45608 (closures don't work in static  
> methods)
> 
> The rest are either assigned or PDO bugs (again, we really really  
> really need someone that looks after PDO).
> 
> Of course there are also still tons of open 5.2 bugs [1] :(
> 
> regards,
> Lukas Kahwe Smith
> smith@pooteeweet.org
> 
> [1] 
http://bugs.php.net/search.php?cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bug_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begin=0
> -- 
> 
> 
> 
> 
> 

Hi,

For "closures don't work in static methods" (45608), this is because a closure 
declared in a static method will always be called statically.

The example given in the report works if the closure is explicitly declared as 
static, but as shown by the bug report it may be better to implicitly inherit 
the ACC_STATIC flag of the declaring method. It seems that Christian planed 
to add this to his patch but it has never be included.

This could be as simple as this:
http://arnaud.lb.s3.amazonaws.com/closure_static.patch

For "relative paths not resolved correctly" (45044) I added a comment on the 
report about the cause of the bug, but I don't know what is the better way to 
fix that.

Regards,

Arnaud

---

## #39352 — Pierre Joye — 2008-07-26T13:29:14+00:00

URL: https://externals.io/message/39349#39352 · In reply to: #39350

hi!



> Of course there are also still tons of open 5.2 bugs [1] :(

What would be nice is to sort out platform specific bugs (5.2 or 5.3).
There is many "windows" bugs that are not Windows specific, they
should be "*" (all OSes). Once they are sorted out, we can more easily
focus on a given platform (windows in my case).

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

---

## #39355 — Lukas Kahwe Smith — 2008-07-26T20:17:52+00:00

URL: https://externals.io/message/39349#39355 · In reply to: #39349

> - undeprecate ticks: as long as we have no replacement for the signal
>  handling we shouldn't deprecate the only way to do that.

So currently the deprecation warning reads that the feature will be  
removed in PHP 6. We could also tone down the message to not mention a  
specific PHP version for removal. Derick, Marcus, Jani etc have all  
said that they have seen reports of serious issues aka crashes with  
ticks. Tony says he is using tick's and we do not have a replacement  
to offer. But given the fact that even Tony did not come out to say  
that he knows how to fix ticks, it seems like the best compromise is  
to deprecate ticks with a message that it could get removed in any  
minor version release with or without a replacement, but it will kept  
for now.

> - drop __toString() from Closures
> - Do not include 3xx http codes in the fopen wrapper change


Can we get a quick in formal vote on each of the above items?

regards,
Lukas Kahwe Smith
smith@pooteeweet.org

---

## #39356 — Lukas Kahwe Smith — 2008-07-26T20:20:42+00:00

URL: https://externals.io/message/39349#39356 · In reply to: #39355

>
> 
>
> > […]
>
> crashes with ticks. Tony says he is using tick's and we do not have  
> a replacement to offer. But given the fact that even Tony did not  
> come out to say that he knows how to fix ticks, it seems like the  
> best compromise is to deprecate ticks with a message that it could  
> get removed in any minor version release with or without a  
> replacement, but it will kept for now.

+1

> > […]

+1

> > […]


+1

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #39389 — Michal Dziemianko — 2008-07-27T20:01:19+00:00

URL: https://externals.io/message/39349#39389 · In reply to: #39351

Hello,



> On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
> > […]

I have just taken a look at this bug, and the problems seems to be in  
php_request_shutdown function from main/main.c. It just executes  
buffers flush no matter what outcome of the script was (I mean error/ 
success) (somewhere around line 1495):

zend_try {
	php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)  
TSRMLS_CC);
} zend_end_try();

It can be avoided by adding if-stmt checking if there was an error:

if (!PG(last_error_message) || !(PG(last_error_type) & E_ERROR)) {
	zend_try {
		php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)  
TSRMLS_CC);
	} zend_end_try();
}

I am not sure if it is the right solution, or if it does not  
introduce any other problems I am not aware of (I have done "make  
test" and haven;t noticed anything strange.)

Cheers
Michal

> > […]
> http://bugs.php.net/search.php? 
> cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bu 
> g_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begi 
> n=0
> > […]
>
> Hi,
>
> For "closures don't work in static methods" (45608), this is  
> because a closure
> declared in a static method will always be called statically.
>
> The example given in the report works if the closure is explicitly  
> declared as
> static, but as shown by the bug report it may be better to  
> implicitly inherit
> the ACC_STATIC flag of the declaring method. It seems that  
> Christian planed
> to add this to his patch but it has never be included.
>
> This could be as simple as this:
> http://arnaud.lb.s3.amazonaws.com/closure_static.patch
>
> For "relative paths not resolved correctly" (45044) I added a  
> comment on the
> report about the cause of the bug, but I don't know what is the  
> better way to
> fix that.
>
> Regards,
>
> Arnaud