date:20120112

Bug #60713 [Opn]: MD5 checksums doesn't match

2012-01-12 Thread ilgroup9 at hotmail dot com

Edit report at https://bugs.php.net/bug.php?id=60713&edit=1

 ID: 60713
 User updated by:ilgroup9 at hotmail dot com
 Reported by:ilgroup9 at hotmail dot com
 Summary:MD5 checksums doesn't match
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   windows xp
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Thank you
You are right
Its all good now.

David


Previous Comments:

[2012-01-13 06:47:34] phpmpan at mpan dot pl

Should be "any file you download". Sorry, was editing the message. Also it is 
addressed to David, not pajoye.


[2012-01-12 01:08:32] phpmpan at mpan dot pl

The problem is not which version is being downloaded. You will get wrong 
checksum for any file he downloads. Sentence "in both option I get shorter 
checksum by 8 digits" and a name of used application clearly suggest that 
you're calculating MD5 instad of SHA1.

Therefore the problem lies between chair and keyboard, not in PHP.


[2012-01-11 15:27:33] paj...@php.net

Move to 5.3, 5.2 are there for convenience only.


[2012-01-11 15:00:59] ilgroup9 at hotmail dot com

Description:

Hello,

I have downloaded several time a file but checksums don't match.

URL: http://windows.php.net/download/

Files:
1. PHP 5.2 (5.2.17)
   VC6 x86 Non Thread Safe (2011-Mar-22 13:28:39)
   # Installer [20.24MB]
   sha1: 2145f6adf72ab5f9a067c52163c6b1c18c47eedd 
2. # Installer [20.41MB]
   sha1: 710a69733aa280f22c86e8b868c51f5796f0a390 

In both option I get shorter checksum by 8 digits.

I have downloaded the files several time with Opera and Firefox browsers  
I have checked the files using the file downloaded from the following URL:
http://www.softpedia.com/progDownload/MD5-Checker-Download-22900.html

I have attached the checker to this report.

Please Advise,

Kind Regards
David 







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60713&edit=1

Bug #60713 [Com]: MD5 checksums doesn't match

2012-01-12 Thread phpmpan at mpan dot pl

Edit report at https://bugs.php.net/bug.php?id=60713&edit=1

 ID: 60713
 Comment by: phpmpan at mpan dot pl
 Reported by:ilgroup9 at hotmail dot com
 Summary:MD5 checksums doesn't match
 Status: Open
 Type:   Bug
 Package:*General Issues
 Operating System:   windows xp
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Should be "any file you download". Sorry, was editing the message. Also it is 
addressed to David, not pajoye.


Previous Comments:

[2012-01-12 01:08:32] phpmpan at mpan dot pl

The problem is not which version is being downloaded. You will get wrong 
checksum for any file he downloads. Sentence "in both option I get shorter 
checksum by 8 digits" and a name of used application clearly suggest that 
you're calculating MD5 instad of SHA1.

Therefore the problem lies between chair and keyboard, not in PHP.


[2012-01-11 15:27:33] paj...@php.net

Move to 5.3, 5.2 are there for convenience only.


[2012-01-11 15:00:59] ilgroup9 at hotmail dot com

Description:

Hello,

I have downloaded several time a file but checksums don't match.

URL: http://windows.php.net/download/

Files:
1. PHP 5.2 (5.2.17)
   VC6 x86 Non Thread Safe (2011-Mar-22 13:28:39)
   # Installer [20.24MB]
   sha1: 2145f6adf72ab5f9a067c52163c6b1c18c47eedd 
2. # Installer [20.41MB]
   sha1: 710a69733aa280f22c86e8b868c51f5796f0a390 

In both option I get shorter checksum by 8 digits.

I have downloaded the files several time with Opera and Firefox browsers  
I have checked the files using the file downloaded from the following URL:
http://www.softpedia.com/progDownload/MD5-Checker-Download-22900.html

I have attached the checker to this report.

Please Advise,

Kind Regards
David 







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60713&edit=1

Bug #60725 [Com]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread idlesign at yandex dot ru

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Comment by: idlesign at yandex dot ru
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

@anon,

Patient answer that was, thank you :) Crivens! Completely missed that "OS: 
fedora core 16 x64" thing. Sorry to bother.


Previous Comments:

[2012-01-13 04:43:02] a dot dobkin at drweb dot com

Oh.. just missed it. thanks!


[2012-01-12 14:33:22] anon at anon dot anon

@a.dobkin, @idlesign

x64 int is 4 bytes, long is 8 bytes. In the example zend_parse_parameters is 
being told to write 8 bytes into a 4 byte variable, and the address where the 
high 4 bytes would be if they existed happens to be (although this is platform 
specific and undefined) the address of the int string length. It's completely 
to be expected.

If you're telling zend_parse_parameters you're giving it a long (as in "sls") 
then actually give it one. I.e., "long p_long;".


[2012-01-12 13:04:28] idlesign at yandex dot ru

@cataphract, 

Sorry, don't get you: from what do you deduce that that is a "platform specific 
undefined behavior"? This behaviour you can easily stumble upon after 5.3.6 if 
develop module. 

>From what I've seen that is a regression as it is, and those guys having first 
>param string alongside with, let's say long, wanting to rely on string lenght 
>param are screwed up after 5.3.6 since they got bloody 0 instead of actual 
>length.


[2012-01-12 12:45:54] cataphr...@php.net

As felipe as said "l" is for "long". This bug tracker is not the place to 
explain platform specific undefined behavior.


[2012-01-12 11:11:55] a dot dobkin at drweb dot com

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60725


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60725&edit=1

Bug #60725 [Com]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread a dot dobkin at drweb dot com

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Comment by: a dot dobkin at drweb dot com
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Oh.. just missed it. thanks!


Previous Comments:

[2012-01-12 14:33:22] anon at anon dot anon

@a.dobkin, @idlesign

x64 int is 4 bytes, long is 8 bytes. In the example zend_parse_parameters is 
being told to write 8 bytes into a 4 byte variable, and the address where the 
high 4 bytes would be if they existed happens to be (although this is platform 
specific and undefined) the address of the int string length. It's completely 
to be expected.

If you're telling zend_parse_parameters you're giving it a long (as in "sls") 
then actually give it one. I.e., "long p_long;".


[2012-01-12 13:04:28] idlesign at yandex dot ru

@cataphract, 

Sorry, don't get you: from what do you deduce that that is a "platform specific 
undefined behavior"? This behaviour you can easily stumble upon after 5.3.6 if 
develop module. 

>From what I've seen that is a regression as it is, and those guys having first 
>param string alongside with, let's say long, wanting to rely on string lenght 
>param are screwed up after 5.3.6 since they got bloody 0 instead of actual 
>length.


[2012-01-12 12:45:54] cataphr...@php.net

As felipe as said "l" is for "long". This bug tracker is not the place to 
explain platform specific undefined behavior.


[2012-01-12 11:11:55] a dot dobkin at drweb dot com

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1


[2012-01-12 11:11:16] idlesign at yandex dot ru

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60725


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60725&edit=1

[PHP-BUG] Req #60738 [NEW]: Allow 'set_error_handler' to handle NULL

2012-01-12 Thread four dot zerooneunauthorized at gmail dot com

From: 
Operating system: irrelivant
PHP version:  5.3.9
Package:  Unknown/Other Function
Bug Type: Feature/Change Request
Bug description:Allow 'set_error_handler' to handle NULL

Description:

Can the 'set_error_handler' function be made to accept NULL as the
parameter in such a way as to reset this feature to the default state of
-no- handler being set?  This would duplicate the behavior of the
'set_exception_handler' function.

Note: this change should not interfere with the 'restore_error_handler'
function.

And as for the 'set_exception_handler' function - if NULL is given as a
parameter, can the return value of 'set_exception_handler' be set to the
details of the previously set exception handler function (string or array)
instead of always '(bool) true' as it now does?

Test script:
---
function testhandler1($errno= null, $errstr= null, $errfile= null, $errline
= null)
{
error_log('1: ' . print_r(func_get_args(), true));
die();
}

function testhandler2($errno= null, $errstr= null, $errfile= null, $errline
= null)
{
error_log('2: ' . print_r(func_get_args(), true));
die();
}

var_dump(set_error_handler('testhandler1'));
var_dump(set_error_handler('testhandler2'));
var_dump(set_error_handler(null));


Expected result:

NULL
string(12) "testhandler1"
string(12) "testhandler2"

Actual result:
--
On line 'var_dump(set_error_handler(null));', a 'set_error_handler()
expects the argument () to be a valid callback' error is generated and
handled by function "testhandler2"

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60738&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60738&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60738&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60738&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60738&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60738&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60738&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60738&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60738&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60738&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60738&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60738&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60738&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60738&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60738&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60738&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60738&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60738&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60738&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60738&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60738&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60738&r=mysqlcfg

Bug #60733 [Asn->Csd]: strtotime bug in php 5.3.9

2012-01-12 Thread gui

Edit report at https://bugs.php.net/bug.php?id=60733&edit=1

 ID: 60733
 Updated by: g...@php.net
 Reported by:paul at minimoo dot org
 Summary:strtotime bug in php 5.3.9
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux(debian)-64bit
 PHP Version:5.3.9
 Assigned To:gui
 Block user comment: N
 Private report: N

 New Comment:

This issue has been fixed in the latest Dotdeb packages.Be sure to upgrade at 
least :
  * to 5.3.9-0~dotdeb.3 if you're running Squeeze 
  * to 5.3.9-0~dotdeb.2 if you're running Lenny

Please send future Dotdeb-specific issues directly on http://www.dotdeb.org/ or 
on my email.


Previous Comments:

[2012-01-12 22:38:21] g...@php.net

It seems to be a Dotdeb-specific issue, I'm looking for a fix. No need to post 
it 
here without warning me first.


[2012-01-12 22:37:24] paul at minimoo dot org

This is looking like it may be an issue with the dotdeb.org build of 5.3.9 - 
have had 3-4 people confirm that this code breaks with the .deb files at 
http://dotdeb.mirror.somersettechsolutions.co.uk/dists/stable/php5/binary-amd64/
 

and 2 people unable to reproduce from a build from latest svn


[2012-01-12 21:29:59] paul at minimoo dot org

Description:

Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8 to 
php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's, minimised 
to 1 line of php.

Valgrind/GDB output attached

Test script:
---
echo strtotime('2011-01-1 00:00 UTC');

Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725=

Bug #28567 [Com]: Ticks crash Apache SAPI

2012-01-12 Thread halmai at sol dot cc dot u-szeged dot hu

Edit report at https://bugs.php.net/bug.php?id=28567&edit=1

 ID: 28567
 Comment by: halmai at sol dot cc dot u-szeged dot hu
 Reported by:solace at ezmail dot ru
 Summary:Ticks crash Apache SAPI
 Status: Bogus
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Win*
 PHP Version:4.3.6
 Block user comment: N
 Private report: N

 New Comment:

The bug still exists. Code is:



apache access log is empty, error log is the following:

httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
[Fri Jan 13 02:19:27 2012] [notice] Apache/2.2.21 (Win32) PHP/5.2.17 configured 
-- resuming normal operations
[Fri Jan 13 02:19:27 2012] [notice] Server built: Sep  9 2011 10:26:10
[Fri Jan 13 02:19:27 2012] [notice] Parent: Created child process 5196
httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
[Fri Jan 13 02:19:27 2012] [notice] Child 5196: Child process is running
[Fri Jan 13 02:19:27 2012] [notice] Child 5196: Acquired the start mutex.
[Fri Jan 13 02:19:27 2012] [notice] Child 5196: Starting 64 worker threads.
[Fri Jan 13 02:19:27 2012] [notice] Child 5196: Starting thread to listen on 
port 80.
[Fri Jan 13 02:19:36 2012] [notice] Parent: child process exited with status 
3221225477 -- Restarting.
httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
[Fri Jan 13 02:19:36 2012] [notice] Apache/2.2.21 (Win32) PHP/5.2.17 configured 
-- resuming normal operations
[Fri Jan 13 02:19:36 2012] [notice] Server built: Sep  9 2011 10:26:10
[Fri Jan 13 02:19:36 2012] [notice] Parent: Created child process 5880
httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
httpd.exe: Could not reliably determine the server's fully qualified domain 
name, using 192.168.0.5 for ServerName
[Fri Jan 13 02:19:36 2012] [notice] Child 5880: Child process is running
[Fri Jan 13 02:19:36 2012] [notice] Child 5880: Acquired the start mutex.
[Fri Jan 13 02:19:36 2012] [notice] Child 5880: Starting 64 worker threads.
[Fri Jan 13 02:19:36 2012] [notice] Child 5880: Starting thread to listen on 
port 80.

Software versions: 
PHP Version 5.2.17
Apache Version: Apache/2.2.21 (Win32) PHP/5.2.17 
OS: Windows XP Home Edition 2002 SP3


Previous Comments:

[2004-07-06 01:40:42] sni...@php.net

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

(Can't find the existing report right now, too slow connection, but try with 
"ticks crash")



[2004-05-31 16:40:31] solace at ezmail dot ru

"How to generate a backtrace" page is for *nix platforms, but this bug appears 
ONLY on Windows. All I have is event in system log "Application error 
Apache.exe at address x". Even Apache doesn't report it in error.log or 
access.log, like bug script wasn't accessed at all (Apache 1.3.27). But Windows 
wants to send report to Microsoft twice.
And I'm not alone with this bug...


[2004-05-31 12:07:04] der...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Works for me...


[2004-05-29 10:18:34] solace at ezmail dot ru

Description:

This bug was reported some time ago, was closed, but still exists. I wrote 
profiler class and posted on phpclasses. And people all over the world start to 
ask me why their apache crashes.
At least if you can't fix it, then mention in documention that ticks are only 
for non-windows platforms and console php (works fine from command line, 
crashes only sapi).


Reproduce code:
---



Actual result:
--
crash






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=28567&edit=1

Bug #60254 [Com]: PHPIniDir format incorrect

2012-01-12 Thread agvulp-forums at yahoo dot com

Edit report at https://bugs.php.net/bug.php?id=60254&edit=1

 ID: 60254
 Comment by: agvulp-forums at yahoo dot com
 Reported by:p dot duda at lumasenseinc dot com
 Summary:PHPIniDir format incorrect
 Status: Assigned
 Type:   Bug
 Package:Windows Installer
 Operating System:   Window 7
 PHP Version:5.3.8
 Assigned To:jmertic
 Block user comment: N
 Private report: N

 New Comment:

Confirmed.

I just installed Apache 2.2 and PHP 5.3.8 in Windows.

The PHP installer asks for the location of the Apache httpd.conf file, so it 
can amend these lines to the end of it.

#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
PHPIniDir "C:\PHP\"
LoadModule php5_module "C:\WEB\PHP\php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL

However.  Apache 2.2 (and others?) anticipates forward slashes instead of back 
slashes, and will transmogrify the two internally when it actually goes to read 
the file.  (Apache literally replaces '\' with '/' and '/' with '\' when 
compiled for Windows.)

Solution.  The above line should be:

PHPIniDir "C:/PHP/"

Eric


Previous Comments:

[2011-11-09 20:56:17] p dot duda at lumasenseinc dot com

Description:

When installing php into a different directory on Windows the installer amends 
the httpd.conf file with the PHPIniDir using backslashes in the path.  This 
renders the directive useless, and php looks for the ini file elsewhere. 
Changing the path to forward slashes resolves the problem.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60254&edit=1

Bug #60733 [Csd->Asn]: strtotime bug in php 5.3.9

2012-01-12 Thread gui

Edit report at https://bugs.php.net/bug.php?id=60733&edit=1

 ID: 60733
 Updated by: g...@php.net
 Reported by:paul at minimoo dot org
 Summary:strtotime bug in php 5.3.9
-Status: Closed
+Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux(debian)-64bit
 PHP Version:5.3.9
-Assigned To:
+Assigned To:gui
 Block user comment: N
 Private report: N

 New Comment:

It seems to be a Dotdeb-specific issue, I'm looking for a fix. No need to post 
it 
here without warning me first.


Previous Comments:

[2012-01-12 22:37:24] paul at minimoo dot org

This is looking like it may be an issue with the dotdeb.org build of 5.3.9 - 
have had 3-4 people confirm that this code breaks with the .deb files at 
http://dotdeb.mirror.somersettechsolutions.co.uk/dists/stable/php5/binary-amd64/
 

and 2 people unable to reproduce from a build from latest svn


[2012-01-12 21:29:59] paul at minimoo dot org

Description:

Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8 to 
php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's, minimised 
to 1 line of php.

Valgrind/GDB output attached

Test script:
---
echo strtotime('2011-01-1 00:00 UTC');

Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725

Bug #60733 [Opn->Csd]: strtotime bug in php 5.3.9

2012-01-12 Thread paul at minimoo dot org

Edit report at https://bugs.php.net/bug.php?id=60733&edit=1

 ID: 60733
 User updated by:paul at minimoo dot org
 Reported by:paul at minimoo dot org
 Summary:strtotime bug in php 5.3.9
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   linux(debian)-64bit
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

This is looking like it may be an issue with the dotdeb.org build of 5.3.9 - 
have had 3-4 people confirm that this code breaks with the .deb files at 
http://dotdeb.mirror.somersettechsolutions.co.uk/dists/stable/php5/binary-amd64/
 

and 2 people unable to reproduce from a build from latest svn


Previous Comments:

[2012-01-12 21:29:59] paul at minimoo dot org

Description:

Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8 to 
php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's, minimised 
to 1 line of php.

Valgrind/GDB output attached

Test script:
---
echo strtotime('2011-01-1 00:00 UTC');

Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for 
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4D4: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanu

[PHP-BUG] Bug #60734 [NEW]: POST, SKIPIF and CLEAN fail if phpt path has spaces

2012-01-12 Thread danielc at analysisandsolutions dot com

From: 
Operating system: 
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Bug
Bug description:POST, SKIPIF and CLEAN fail if phpt path has spaces

Description:

The POST, SKIPIF and CLEAN sections for phpt fail to execute if the path to
the test file has spaces in it.  Will attach a patch for run-tests.php.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60734&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60734&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60734&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60734&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60734&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60734&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60734&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60734&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60734&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60734&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60734&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60734&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60734&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60734&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60734&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60734&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60734&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60734&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60734&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60734&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60734&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60734&r=mysqlcfg

[PHP-BUG] Bug #60733 [NEW]: strtotime bug in php 5.3.9

2012-01-12 Thread paul at minimoo dot org

From: 
Operating system: linux(debian)-64bit
PHP version:  5.3.9
Package:  Reproducible crash
Bug Type: Bug
Bug description:strtotime bug in php 5.3.9 

Description:

Since upgrading [using dotdeb.org compiled version of php] from php 5.3.8
to php 5.3.9, strtotime appears to crash. This occurs for me on 2 VM's,
minimised to 1 line of php.

Valgrind/GDB output attached

Test script:
---
echo strtotime('2011-01-1 00:00 UTC');

Actual result:
--
valgrind /usr/bin/php test.php
==25725== Memcheck, a memory error detector
==25725== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==25725== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==25725== Command: /usr/bin/php test.php
==25725==
129384==25725== Invalid read of size 8
==25725==at 0x45D494: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcf90 is 0 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4A8: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb0 is 32 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4BE: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfb8 is 40 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25725==by 0x755755: main (in /usr/bin/php5)
==25725==
==25725== Invalid read of size 8
==25725==at 0x45D4D4: timelib_tzinfo_dtor (in /usr/bin/php5)
==25725==by 0x6D1217: zend_hash_destroy (in /usr/bin/php5)
==25725==by 0x437BF0: zm_deactivate_date (in /usr/bin/php5)
==25725==by 0x6C645B: module_registry_cleanup (in /usr/bin/php5)
==25725==by 0x6D0FA3: zend_hash_reverse_apply (in /usr/bin/php5)
==25725==by 0x6C4E7C: zend_deactivate_modules (in /usr/bin/php5)
==25725==by 0x66FDB4: php_request_shutdown (in /usr/bin/php5)
==25725==by 0x7547FF: main (in /usr/bin/php5)
==25725==  Address 0x8bdcfc0 is 48 bytes inside a block of size 112 free'd
==25725==at 0x4C240FD: free (vg_replace_malloc.c:366)
==25725==by 0x435599: zif_strtotime (in /usr/bin/php5)
==25725==by 0x715839: zend_do_fcall_common_helper_SPEC (in
/usr/bin/php5)
==25725==by 0x6ECC5F: execute (in /usr/bin/php5)
==25725==by 0x6C3FAC: zend_execute_scripts (in /usr/bin/php5)
==25725==by 0x66F147: php_execute_script (in /usr/bin/php5)
==25

Bug #60727 [Opn->Bgs]: summary?

2012-01-12 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=60727&edit=1

 ID: 60727
 Updated by: cataphr...@php.net
 Reported by:felix at codingshare dot de
 Summary:summary?
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Sockets related
 Operating System:   openSuse
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:

[2012-01-12 14:13:29] felix at codingshare dot de

Description:

Fatal error: Call to undefined function socket_create() in 
/home/faust/public_html/mysql/index.php on line 83

Test script:
---
function ping($host, $timeout = 1) {
/* ICMP ping packet with a pre-calculated checksum */
$package = "\x08\x00\x7d\x4b\x00\x00\x00\x00PingHost";
$socket  = socket_create(AF_INET, SOCK_RAW, 1);
socket_set_option($socket, SOL_SOCKET, SO_RCVTIMEO, array('sec' 
=> $timeout, 'usec' => 0));
socket_connect($socket, $host, null);

$ts = microtime(true);
socket_send($socket, $package, strLen($package), 0);
if (socket_read($socket, 255))
$result = microtime(true) - $ts;
else$result = false;
socket_close($socket);

return $result;
}
echo ping("google.de");







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60727&edit=1

Bug #60714 [Opn->Bgs]: htmlspecialchars() ignore default_charset value

2012-01-12 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=60714&edit=1

 ID: 60714
 Updated by: cataphr...@php.net
 Reported by:mahatma at bspu dot unibel dot by
 Summary:htmlspecialchars() ignore default_charset value
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:*Languages/Translation
 Operating System:   linux
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Closing.


Previous Comments:

[2012-01-12 17:43:43] ras...@php.net

Yes, I understand why it breaks sites using cp1251. However, it was sort of 
dumb 
luck that they weren't broken before due to iso-8859-1 and cp1251 getting 
along. 
htmlspecialchars has direct support for cp1251, so if you are passing that in 
you 
should tell it, or set the default_charset and tell htmlspecialchars to use the 
default by passing in '' as the charset. On the whole I firmly believe we have 
made more sites secure than we have broken with this change.


[2012-01-12 11:10:16] cataphr...@php.net

The problem is changing the default from ISO-8859-1 to UTF-8. The ISO-8859-1 
default was good for CP 1251 because the encoded characters are represented the 
same way (using htmlentities, however, would be a problem). The break in 5.4 is 
that the default was changed from ISO-8859-1  to UTF-8, and CP 1251 byte 
streams, in general, are not valid UTF-8 bytestreams, even though the encoded 
characters are represented the same way. This causes htmlspecialchars to error 
out and return an empty string.


[2012-01-12 08:47:08] ras...@php.net

There was discussion. Simply changing the not-specified case to use the 
default_charset setting would break a lot of code. However, since it is a 
useful 
feature, it is supported through the empty string case as documented at 
http://php.net/htmlspecialchars


[2012-01-11 22:50:11] cataphr...@php.net

Yes, there's a BC break in 5.4 in this respect. You can make htmlspecialchars 
use default_charset, but you'd still have to change all the calls to use the 
empty string as charset.

I'm leaving this open for now, as this change was made without any discussion I 
remember.


[2012-01-11 15:38:30] mahatma at bspu dot unibel dot by

Description:

Since default charset changed, I got compatibility problem - htmlspecialchars() 
start to strip cp1251 (or any non-unicode) national symbols and no way to 
change another default charset. But looks like default_charset is provided for 
similar goals (and, ideally - charset= html detection too).

I suggest just to get default charset for htmlspecialchars() (and IMHO for 
htmlentities()) from default_charset.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60714&edit=1

Bug #52975 [Com]: VC10 Builds Wanted

2012-01-12 Thread marc at misterphp dot com

Edit report at https://bugs.php.net/bug.php?id=52975&edit=1

 ID: 52975
 Comment by: marc at misterphp dot com
 Reported by:xiaomao5 at live dot com
 Summary:VC10 Builds Wanted
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Windows
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

+1 vor vc10


Previous Comments:

[2010-10-02 22:30:59] paj...@php.net

Next PHP major release should be compiler independent or almost independent.

As of now it is VC9 the standard. Remember that VC10 has been released this 
year while 5.3 has been released in June 2009.

But no bug or feature request, already part of the roadmap > bogus.


[2010-10-02 22:18:20] xiaomao5 at live dot com

Description:

I have Visual Studio 2010 and Windows SDK for Windows 7 and .NET 4. When I am 
compiling Windows extensions for PHP. PHP's VC9 build doesn't work with it. I 
have to compile the whole PHP. but I want to publish them to help other people 
that don't have compilers. If I publish the whole php vc10 build myself. Other 
people will afraid i add virus in it. Can PHP release official vc10 build??







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=52975&edit=1

Bug #60462 [Com]: When APC is enabled segfault

2012-01-12 Thread josh at joshbutts dot com

Edit report at https://bugs.php.net/bug.php?id=60462&edit=1

 ID: 60462
 Comment by: josh at joshbutts dot com
 Reported by:henrik at bjrnskov dot dk
 Summary:When APC is enabled segfault
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Mac OS X 10.7
 PHP Version:5.4.0RC2
 Block user comment: N
 Private report: N

 New Comment:

Happens also in 5.4RC5 with APC from pecl on OSX 10.7.3


Previous Comments:

[2011-12-28 15:50:26] henrik at bjrnskov dot dk

Just tried compiling a 5.4RC4 manually and installing apc from svn and pecl.

both php-fpm and apache2 module segfaults.

OS X Lion 10.7.3


[2011-12-17 11:14:35] lolautruche at gmail dot com

Here : http://svn.php.net/repository/pecl/apc/


[2011-12-17 11:10:53] henrik at bjrnskov dot dk

Where is apc svn ?


[2011-12-16 17:55:26] lolautruche at gmail dot com

no more segfault with latest php 5.4 build and APC built from trunk


[2011-12-16 17:34:04] lolautruche at gmail dot com

Hi

I also experience this issue on Linux Ubuntu Server 8.04 LTS




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60462


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60462&edit=1

Bug #60051 [Com]: Compiler is failing while generating phar.php

2012-01-12 Thread CoreyStup at gmail dot com

Edit report at https://bugs.php.net/bug.php?id=60051&edit=1

 ID: 60051
 Comment by: CoreyStup at gmail dot com
 Reported by:sanjay dot d dot patil at oracle dot com
 Summary:Compiler is failing while generating phar.php
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   aix 6.1
 PHP Version:5.3.8
 Block user comment: N
 Private report: N

 New Comment:

The missing htmlDocDumpMemoryFormat symbol is due to a API version change with 
libxml2.   

I too am an AIX user, and have a patch in process to address the issue.


Previous Comments:

[2011-11-08 16:45:48] rmmangin at fedex dot com

I successfully built php 5.3.8 on Solaris 2.8 (at least the ./configure, make, 
and make install steps all reported success).  But trying to restart Apache to 
pick up the new libphp5.so module reports:
Cannot load /opt/apache/modules/libphp5.so into server: ld.so.1: httpd: fatal: 
relocation error: file /opt/apache/modules/libphp5.so: 
symbol htmlDocDumpMemoryFormat: referenced symbol not found

Yet running ldd on libphp5.so shows nothing as "not found".


[2011-10-13 09:53:55] sanjay dot d dot patil at oracle dot com

Description:

We are trying to compile php 5.3.8 on AIX 6.1 using configure options mentioned 
below.

./configure --prefix=/usr/local 
--with-apxs2=/export/opt/quikremit/apache2/bin/apxs 
--with-config-file-path=/export/opt/quikremit/apache2/conf --with-gd 
--with-zlib-dir=/opt/freeware/lib --enable-shared --enable-debug 
--disable-static  --host=powerpc-ibm-aix6.1.0.0 

but make is giveing below error:


Generating phar.php
exec(): 0509-036 Cannot load program 
/export/opt/quikremit/pqapp/php/php-5.3.8/sapi/cli/php because of the following 
errors:
rtld: 0712-001 Symbol htmlDocDumpMemoryFormat was referenced
  from module php(), but a runtime definition
  of the symbol was not found.
rtld: 0712-001 Symbol xmlTextReaderSetup was referenced
  from module php(), but a runtime definition
  of the symbol was not found.
make: *** [ext/phar/phar.php] Error 255

Test script:
---
ext/phar/phar.php: 
/export/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/build_precommand.php 
/export/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/phar/*.inc /exp
ort/opt/quikremit/pqapp/php/php-5.3.8/ext/phar/phar/*.php $(SAPI_CLI_PATH)
-@echo "Generating phar.php"


Expected result:

Make should complete with successful results 
as
BUILD COMPLETE



Actual result:
--
Generating phar.php
exec(): 0509-036 Cannot load program 
/export/opt/quikremit/pqapp/php/php-5.3.8/sapi/cli/php because of the following 
errors:
rtld: 0712-001 Symbol htmlDocDumpMemoryFormat was referenced
  from module php(), but a runtime definition
  of the symbol was not found.
rtld: 0712-001 Symbol xmlTextReaderSetup was referenced
  from module php(), but a runtime definition
  of the symbol was not found.
make: *** [ext/phar/phar.php] Error 255






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60051&edit=1

Bug #60714 [Opn]: htmlspecialchars() ignore default_charset value

2012-01-12 Thread rasmus

Edit report at https://bugs.php.net/bug.php?id=60714&edit=1

 ID: 60714
 Updated by: ras...@php.net
 Reported by:mahatma at bspu dot unibel dot by
 Summary:htmlspecialchars() ignore default_charset value
 Status: Open
 Type:   Bug
 Package:*Languages/Translation
 Operating System:   linux
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Yes, I understand why it breaks sites using cp1251. However, it was sort of 
dumb 
luck that they weren't broken before due to iso-8859-1 and cp1251 getting 
along. 
htmlspecialchars has direct support for cp1251, so if you are passing that in 
you 
should tell it, or set the default_charset and tell htmlspecialchars to use the 
default by passing in '' as the charset. On the whole I firmly believe we have 
made more sites secure than we have broken with this change.


Previous Comments:

[2012-01-12 11:10:16] cataphr...@php.net

The problem is changing the default from ISO-8859-1 to UTF-8. The ISO-8859-1 
default was good for CP 1251 because the encoded characters are represented the 
same way (using htmlentities, however, would be a problem). The break in 5.4 is 
that the default was changed from ISO-8859-1  to UTF-8, and CP 1251 byte 
streams, in general, are not valid UTF-8 bytestreams, even though the encoded 
characters are represented the same way. This causes htmlspecialchars to error 
out and return an empty string.


[2012-01-12 08:47:08] ras...@php.net

There was discussion. Simply changing the not-specified case to use the 
default_charset setting would break a lot of code. However, since it is a 
useful 
feature, it is supported through the empty string case as documented at 
http://php.net/htmlspecialchars


[2012-01-11 22:50:11] cataphr...@php.net

Yes, there's a BC break in 5.4 in this respect. You can make htmlspecialchars 
use default_charset, but you'd still have to change all the calls to use the 
empty string as charset.

I'm leaving this open for now, as this change was made without any discussion I 
remember.


[2012-01-11 15:38:30] mahatma at bspu dot unibel dot by

Description:

Since default charset changed, I got compatibility problem - htmlspecialchars() 
start to strip cp1251 (or any non-unicode) national symbols and no way to 
change another default charset. But looks like default_charset is provided for 
similar goals (and, ideally - charset= html detection too).

I suggest just to get default charset for htmlspecialchars() (and IMHO for 
htmlentities()) from default_charset.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60714&edit=1

Bug #60732 [PATCH]: php_error_docref links to invalid pages

2012-01-12 Thread vr...@php.net

Edit report at https://bugs.php.net/bug.php?id=60732&edit=1

 ID: 60732
 Patch added by: vr...@php.net
 Reported by:vr...@php.net
 Summary:php_error_docref links to invalid pages
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Irrelevant
 PHP Version:5.4SVN-2012-01-12 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: php_error_docref-strip-leading-dashes
Revision:   1326388963
URL:
https://bugs.php.net/patch-display.php?bug=60732&patch=php_error_docref-strip-leading-dashes&revision=1326388963


Previous Comments:

[2012-01-12 17:18:05] vr...@php.net

Description:

Links to PHP Manual generated in case of an error are wrong if the function or 
method begins by __.

Test script:
---
try {
new DateTimeZone("x");
} catch (Exception $e) {
echo $e->getMessage();
}


Expected result:

DateTimeZone::__construct() [datetimezone.construct.php]: Unknown or bad 
timezone (x)

Actual result:
--
DateTimeZone::__construct() [datetimezone.--construct.php]: Unknown or bad 
timezone (x)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60732&edit=1

[PHP-BUG] Bug #60732 [NEW]: php_error_docref links to invalid pages

2012-01-12 Thread vr...@php.net

From: vrana
Operating system: Irrelevant
PHP version:  5.4SVN-2012-01-12 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:php_error_docref links to invalid pages

Description:

Links to PHP Manual generated in case of an error are wrong if the function
or method begins by __.

Test script:
---
try {
new DateTimeZone("x");
} catch (Exception $e) {
echo $e->getMessage();
}


Expected result:

DateTimeZone::__construct() [datetimezone.construct.php]: Unknown or bad
timezone (x)

Actual result:
--
DateTimeZone::__construct() [datetimezone.--construct.php]: Unknown or bad
timezone (x)

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60732&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60732&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60732&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60732&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60732&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60732&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60732&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60732&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60732&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60732&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60732&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60732&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60732&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60732&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60732&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60732&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60732&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60732&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60732&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60732&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60732&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60732&r=mysqlcfg

Bug #48866 [Com]: ldap.conf TLS_REQCERT directive fails for ldaps

2012-01-12 Thread mo at dgi dot no

Edit report at https://bugs.php.net/bug.php?id=48866&edit=1

 ID: 48866
 Comment by: mo at dgi dot no
 Reported by:dev at lechat dot org
 Summary:ldap.conf TLS_REQCERT directive fails for ldaps
 Status: Feedback
 Type:   Bug
 Package:LDAP related
 Operating System:   win32 only - windows server 2003
 PHP Version:5.3.0
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Hello!

I'm still experiencing this issue in PHP 5.3.8 on IIS 7, Win 2008 R2. The most 
peculiar thing is that this issue also arises even though the server has 
installed 
the trusted root CA cert which have issued the LDAP-server cert. I also use the 
LDAP-servers FQDN which matches the cert. 

It strikes me as almost funny to have to disable cert-cheking on a cert i know 
is 
valid. Any one else been experiencing this?


Previous Comments:

[2011-03-28 21:00:38] ocala at udistrital dot edu dot co

OS: Windows 7 64 Bit.
PHP Version 5.3.0
Apache Version 2.2.11
Blunded Like Wamp

Wamp installed in C:\wamp
Script running in G:\www\test.php

LDAP Configuration file in C:\ldap.conf

This settings allows a working ldaps:// connection to a Windows 2008 R2


[2011-03-21 14:26:51] lorenz dot ulrich at phz dot ch

In my Windows 7 machine with PHP 5.3.1, "TLS_REQCERT never" in a file 
"C:\ldap.conf" (was C:\openldap\sysconf\ldap.conf for PHP < 5.3) works fine for 
establishing StartTLS LDAP connections using port 389.


[2011-01-27 12:10:46] julien dot moisan at agrostar dot fr

Same trouble with PHP 5.3.0 with Windows

when i move ldap.conf to c:/ that's work fine.


[2010-11-10 16:53:06] tegwe002 at umn dot edu

Based on other people's comments I did a little testing. Here's what I found 
out.

System:
PHP 5.3.3 Win32 vc6 x86
Windows server 2008 R2 Enterprise (no service pack)
Apache 2.2.15 

We too have our web-root (e) on a different drive than the system root (c). 
Since this machine is in production, I put one copy of the file in each 
location. I tried without reboot and had no joy.

After reboot I was able to connect to ldap over ssl with no errors. 

Then I did a little testing to see which file was being used. I tried moving 
the test script between the c: and e: drives. 

The file must be in the root of the drive that the script is run from. So if 
you run scripts from more than one drive you'll need to copy the file to the 
root of each drive.

I hope this helps someone else.


[2010-06-18 09:40:25] paj...@php.net

Please try 5.3.3RC1




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=48866


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=48866&edit=1

[PHP-BUG] Bug #60730 [NEW]: cannot build mysql.so module with --with-mysql=mysqlnd

2012-01-12 Thread czachary at wiley dot com

From: 
Operating system: Fedora 16
PHP version:  5.3.9
Package:  *Compile Issues
Bug Type: Bug
Bug description:cannot build mysql.so module with --with-mysql=mysqlnd

Description:

I am receiving the following compile issue when trying to compile the
mysql.so in the ext/mysql folder using mysqlnd.  Please see the detail
below.

./configure --prefix=PATH --with-php-config=/x/y/z/bin/php-config
--with-mysql=mysqlnd --with-zlib-dir=/usr

Error:

php-5.3.9/ext/mysql/php_mysql_structs.h:39:33: fatal error:
ext/mysqlnd/mysqlnd.h: No such file or directory
compilation terminated.
make: *** [php_mysql.lo] Error 1


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60730&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60730&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60730&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60730&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60730&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60730&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60730&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60730&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60730&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60730&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60730&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60730&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60730&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60730&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60730&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60730&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60730&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60730&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60730&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60730&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60730&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60730&r=mysqlcfg

Bug #60725 [Com]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread anon at anon dot anon

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Comment by: anon at anon dot anon
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

@a.dobkin, @idlesign

x64 int is 4 bytes, long is 8 bytes. In the example zend_parse_parameters is 
being told to write 8 bytes into a 4 byte variable, and the address where the 
high 4 bytes would be if they existed happens to be (although this is platform 
specific and undefined) the address of the int string length. It's completely 
to be expected.

If you're telling zend_parse_parameters you're giving it a long (as in "sls") 
then actually give it one. I.e., "long p_long;".


Previous Comments:

[2012-01-12 13:04:28] idlesign at yandex dot ru

@cataphract, 

Sorry, don't get you: from what do you deduce that that is a "platform specific 
undefined behavior"? This behaviour you can easily stumble upon after 5.3.6 if 
develop module. 

>From what I've seen that is a regression as it is, and those guys having first 
>param string alongside with, let's say long, wanting to rely on string lenght 
>param are screwed up after 5.3.6 since they got bloody 0 instead of actual 
>length.


[2012-01-12 12:45:54] cataphr...@php.net

As felipe as said "l" is for "long". This bug tracker is not the place to 
explain platform specific undefined behavior.


[2012-01-12 11:11:55] a dot dobkin at drweb dot com

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1


[2012-01-12 11:11:16] idlesign at yandex dot ru

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.


[2012-01-12 10:59:59] fel...@php.net

'l' expects a 'long', not an 'int'




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60725


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60725&edit=1

[PHP-BUG] Bug #60727 [NEW]: summary?

2012-01-12 Thread felix at codingshare dot de

From: 
Operating system: openSuse
PHP version:  5.4.0RC5
Package:  Sockets related
Bug Type: Bug
Bug description:summary?

Description:

Fatal error: Call to undefined function socket_create() in
/home/faust/public_html/mysql/index.php on line 83

Test script:
---
function ping($host, $timeout = 1) {
/* ICMP ping packet with a pre-calculated checksum */
$package = "\x08\x00\x7d\x4b\x00\x00\x00\x00PingHost";
$socket  = socket_create(AF_INET, SOCK_RAW, 1);
socket_set_option($socket, SOL_SOCKET, SO_RCVTIMEO,
array('sec' => $timeout, 'usec' => 0));
socket_connect($socket, $host, null);

$ts = microtime(true);
socket_send($socket, $package, strLen($package), 0);
if (socket_read($socket, 255))
$result = microtime(true) - $ts;
else$result = false;
socket_close($socket);

return $result;
}
echo ping("google.de");


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60727&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60727&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60727&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60727&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60727&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60727&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60727&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60727&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60727&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60727&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60727&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60727&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60727&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60727&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60727&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60727&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60727&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60727&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60727&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60727&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60727&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60727&r=mysqlcfg

Bug #60726 [Opn->Csd]: Class name with namespace in ReflectionClass() returns always false

2012-01-12 Thread otakarek at post dot cz

Edit report at https://bugs.php.net/bug.php?id=60726&edit=1

 ID: 60726
 User updated by:otakarek at post dot cz
 Reported by:otakarek at post dot cz
 Summary:Class name with namespace in ReflectionClass()
 returns always false
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reflection related
 Operating System:   GNU Linux
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

In 5.3.3 ok:
getDocComment());
?>

In 5.3.9 must be:
getDocComment());
?>


Previous Comments:

[2012-01-12 13:39:19] otakarek at post dot cz

Description:

---
>From manual page: 
>http://www.php.net/reflectionclass.getdoccomment#refsect1-reflectionclass.getdoccomment-seealso
---


Test script:
---
getDocComment())
?>

Expected result:

string(55) "/** * A test class * * @param foo bar * @return baz */" 

Actual result:
--
bool(false) 






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60726&edit=1

[PHP-BUG] Bug #60726 [NEW]: Class name with namespace in ReflectionClass() returns always false

2012-01-12 Thread otakarek at post dot cz

From: 
Operating system: GNU Linux
PHP version:  5.3.9
Package:  Reflection related
Bug Type: Bug
Bug description:Class name with namespace in ReflectionClass() returns always 
false

Description:

---
>From manual page:
http://www.php.net/reflectionclass.getdoccomment#refsect1-reflectionclass.getdoccomment-seealso
---


Test script:
---
getDocComment())
?>

Expected result:

string(55) "/** * A test class * * @param foo bar * @return baz */" 

Actual result:
--
bool(false) 

-- 
Edit bug report at https://bugs.php.net/bug.php?id=60726&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60726&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60726&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60726&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60726&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60726&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60726&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60726&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60726&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60726&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60726&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60726&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60726&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60726&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60726&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60726&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60726&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60726&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60726&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60726&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60726&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60726&r=mysqlcfg

Bug #60725 [Com]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread idlesign at yandex dot ru

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Comment by: idlesign at yandex dot ru
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

@cataphract, 

Sorry, don't get you: from what do you deduce that that is a "platform specific 
undefined behavior"? This behaviour you can easily stumble upon after 5.3.6 if 
develop module. 

>From what I've seen that is a regression as it is, and those guys having first 
>param string alongside with, let's say long, wanting to rely on string lenght 
>param are screwed up after 5.3.6 since they got bloody 0 instead of actual 
>length.


Previous Comments:

[2012-01-12 12:45:54] cataphr...@php.net

As felipe as said "l" is for "long". This bug tracker is not the place to 
explain platform specific undefined behavior.


[2012-01-12 11:11:55] a dot dobkin at drweb dot com

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1


[2012-01-12 11:11:16] idlesign at yandex dot ru

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.


[2012-01-12 10:59:59] fel...@php.net

'l' expects a 'long', not an 'int'


[2012-01-12 10:57:56] a dot dobkin at drweb dot com

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first 
parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", 
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code on 
line 1
PHP

Bug #60725 [Opn->Bgs]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Updated by: cataphr...@php.net
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

As felipe as said "l" is for "long". This bug tracker is not the place to 
explain platform specific undefined behavior.


Previous Comments:

[2012-01-12 11:11:55] a dot dobkin at drweb dot com

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1


[2012-01-12 11:11:16] idlesign at yandex dot ru

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.


[2012-01-12 10:59:59] fel...@php.net

'l' expects a 'long', not an 'int'


[2012-01-12 10:57:56] a dot dobkin at drweb dot com

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first 
parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", 
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code on 
line 1
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1


Exemple 4 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "lss", 
&p_long, &p_str1, &p_str1_len, &p_str2, &p_str2_len)) {
return;
}

zend_error(E_WARNING, "First parameter: '%d'", p_long);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str1, 
p_st

Bug #60725 [Opn]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread a dot dobkin at drweb dot com

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 User updated by:a dot dobkin at drweb dot com
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Incorrect parsing first parameter when type_spec = "sls" (e.g.) 
zend_parse_parameter() return string length as 0, always. See example #1 and #2:

PHP Warning:  First parameter: 'first' and it len: 0 in Command line code on 
line 1


Previous Comments:

[2012-01-12 11:11:16] idlesign at yandex dot ru

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.


[2012-01-12 10:59:59] fel...@php.net

'l' expects a 'long', not an 'int'


[2012-01-12 10:57:56] a dot dobkin at drweb dot com

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first 
parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", 
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code on 
line 1
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1


Exemple 4 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "lss", 
&p_long, &p_str1, &p_str1_len, &p_str2, &p_str2_len)) {
return;
}

zend_error(E_WARNING, "First parameter: '%d'", p_long);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters(123, "second", "third");'

Output:

PHP Warning:  First parameter: '123' in Command line code on line

Bug #60725 [Com]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread idlesign at yandex dot ru

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Comment by: idlesign at yandex dot ru
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

@felipe, do you read what subject says? 

Please elaborate on "'l' expects a 'long', not an 'int'" of yours and on how 
does it relate to the problem.

This ticket is about string length param is set to 0 upon specified 
circumstances.


Previous Comments:

[2012-01-12 10:59:59] fel...@php.net

'l' expects a 'long', not an 'int'


[2012-01-12 10:57:56] a dot dobkin at drweb dot com

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first 
parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", 
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code on 
line 1
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1


Exemple 4 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "lss", 
&p_long, &p_str1, &p_str1_len, &p_str2, &p_str2_len)) {
return;
}

zend_error(E_WARNING, "First parameter: '%d'", p_long);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters(123, "second", "third");'

Output:

PHP Warning:  First parameter: '123' in Command line code on line 1
PHP Warning:  Second parameter: 'second' and it len: 5 in Command line code on 
line 1
PHP Warning:  Third parameter: 'third' and it len: 6 in Command line code on 
line 1








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60725&edit=1

Bug #60714 [Opn]: htmlspecialchars() ignore default_charset value

2012-01-12 Thread cataphract

Edit report at https://bugs.php.net/bug.php?id=60714&edit=1

 ID: 60714
 Updated by: cataphr...@php.net
 Reported by:mahatma at bspu dot unibel dot by
 Summary:htmlspecialchars() ignore default_charset value
 Status: Open
 Type:   Bug
 Package:*Languages/Translation
 Operating System:   linux
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

The problem is changing the default from ISO-8859-1 to UTF-8. The ISO-8859-1 
default was good for CP 1251 because the encoded characters are represented the 
same way (using htmlentities, however, would be a problem). The break in 5.4 is 
that the default was changed from ISO-8859-1  to UTF-8, and CP 1251 byte 
streams, in general, are not valid UTF-8 bytestreams, even though the encoded 
characters are represented the same way. This causes htmlspecialchars to error 
out and return an empty string.


Previous Comments:

[2012-01-12 08:47:08] ras...@php.net

There was discussion. Simply changing the not-specified case to use the 
default_charset setting would break a lot of code. However, since it is a 
useful 
feature, it is supported through the empty string case as documented at 
http://php.net/htmlspecialchars


[2012-01-11 22:50:11] cataphr...@php.net

Yes, there's a BC break in 5.4 in this respect. You can make htmlspecialchars 
use default_charset, but you'd still have to change all the calls to use the 
empty string as charset.

I'm leaving this open for now, as this change was made without any discussion I 
remember.


[2012-01-11 15:38:30] mahatma at bspu dot unibel dot by

Description:

Since default charset changed, I got compatibility problem - htmlspecialchars() 
start to strip cp1251 (or any non-unicode) national symbols and no way to 
change another default charset. But looks like default_charset is provided for 
similar goals (and, ideally - charset= html detection too).

I suggest just to get default charset for htmlspecialchars() (and IMHO for 
htmlentities()) from default_charset.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60714&edit=1

Bug #26678 [Com]: preg_quote doesn't quote forward slashes

2012-01-12 Thread vovan-ve at yandex dot ru

Edit report at https://bugs.php.net/bug.php?id=26678&edit=1

 ID: 26678
 Comment by: vovan-ve at yandex dot ru
 Reported by:gnif at spacevs dot com
 Summary:preg_quote doesn't quote forward slashes
 Status: Bogus
 Type:   Bug
 Package:*Regular Expressions
 Operating System:   Debain
 PHP Version:4.3.2
 Block user comment: N
 Private report: N

 New Comment:

I'm sorry for necroposting.

Why optional value for $delimiter is NULL? I cannot understand, when I must not 
escape any delimiter? PCRE always requires delimiter for regexp. I think, there 
are no such situation, when delimiter can be omitted.

OTOH, preg_quote() must not suppose, that delimiter is slash by default due to 
there are no defaults to delimiter in regexp. In this case, why $delimiter _is_ 
optional?


Previous Comments:

[2003-12-20 02:50:19] e...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

see http://www.php.net/preg_quote 

echo preg_quote($file, \"/\");



[2003-12-19 21:58:20] gnif at spacevs dot com

Description:

if you use preg_quote to escape a string with forward slashes in it, it doesn't 
quote them.

Reproduce code:
---
$file = 'pages/box/test.php';
echo preg_quote($file);

Expected result:

pages\/box\/test\.php

Actual result:
--
pages/box/test\.php






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=26678&edit=1

Bug #60725 [Opn]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread felipe

Edit report at https://bugs.php.net/bug.php?id=60725&edit=1

 ID: 60725
 Updated by: fel...@php.net
 Reported by:a dot dobkin at drweb dot com
 Summary:zend_parse_parameters(): Incorrect parsing of the
 first parameter
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   fedora core 16 x64
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

'l' expects a 'long', not an 'int'


Previous Comments:

[2012-01-12 10:57:56] a dot dobkin at drweb dot com

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first 
parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line code 
>>> on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss", 
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code on 
line 1
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code on 
line 1


Exemple 4 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "lss", 
&p_long, &p_str1, &p_str1_len, &p_str2, &p_str2_len)) {
return;
}

zend_error(E_WARNING, "First parameter: '%d'", p_long);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters(123, "second", "third");'

Output:

PHP Warning:  First parameter: '123' in Command line code on line 1
PHP Warning:  Second parameter: 'second' and it len: 5 in Command line code on 
line 1
PHP Warning:  Third parameter: 'third' and it len: 6 in Command line code on 
line 1








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60725&edit=1

[PHP-BUG] Bug #60725 [NEW]: zend_parse_parameters(): Incorrect parsing of the first parameter

2012-01-12 Thread a dot dobkin at drweb dot com

From: 
Operating system: fedora core 16 x64
PHP version:  5.3.9
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:zend_parse_parameters(): Incorrect parsing of the first 
parameter

Description:

Incorrect parsing of the first parameter if it's 
has type of 'string' and one of next parameter  has type of  'long'. 
Function zend_parse_parameters() always return string length as 0 of first

parameter. Error is present in versions 5.3.7-5.3.9. In version 5.3.6 there
is 
no error

On php v 5.3.6 it's correctly  works

Example 1 (Error):

PHP_FUNCTION(test_parse_parameters) {
char *p_str1 = NULL;
char *p_str2 = NULL;

int p_long;
int p_str1_len;
int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sls", 
&p_str1, &p_str1_len, &p_long, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%d'", p_long);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:
[antonio@antonio]# php -r 'test_parse_parameters("first", 123, "third");'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line
code on 
line 1 <<<
PHP Warning:  Second parameter: '123' in Command line code on line 1
PHP Warning:  Third parameter: 'third' and it len: 5 in Command line code
on 
line 1


Exemple 2 (Error):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ssl", 
&p_str1, &p_str1_len, &p_str2, &p_str2_len, &p_long)) {
return;
}

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2,

p_str2_len);
zend_error(E_WARNING, "Third parameter: '%d'", p_long);
}

Run:

[antonio@antonio]# php -r 'dwavd_init("first", "second", 123);'

Output:

>>> PHP Warning:  First parameter: 'first' and it len: 0 in Command line
code on 
line 1 <<<
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code
on 
line 1
PHP Warning:  Third parameter: '123' in Command line code on line 1


Exemple 3 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss",
&p_str1, 
&p_str1_len, &p_str2, &p_str2_len)) {
return;
  }

zend_error(E_WARNING, "First parameter: '%s' and it len: %d", p_str1, 
p_str1_len);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str2,

p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters("first", "second");'

Output:

PHP Warning:  First parameter: 'first' and it len: 5 in Command line code
on 
line 1
PHP Warning:  Second parameter: 'second' and it len: 6 in Command line code
on 
line 1


Exemple 4 (OK):

PHP_FUNCTION(test_parse_parameters) {
  char *p_str1 = NULL;
  char *p_str2 = NULL;

  int p_str1_len;
  int p_str2_len;
  int p_long;

  if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "lss", 
&p_long, &p_str1, &p_str1_len, &p_str2, &p_str2_len)) {
return;
}

zend_error(E_WARNING, "First parameter: '%d'", p_long);  
zend_error(E_WARNING, "Second parameter: '%s' and it len: %d", p_str1,

p_str1_len);  
zend_error(E_WARNING, "Third parameter: '%s' and it len: %d", p_str2, 
p_str2_len);
}

Run:

[antonio@antonio]#  php -r 'test_parse_parameters(123, "second",
"third");'

Output:

PHP Warning:  First parameter: '123' in Command line code on line 1
PHP Warning:  Second parameter: 'second' and it len: 5 in Command line code
on 
line 1
PHP Warning:  Third parameter: 'third' and it len: 6 in Command line code
on 
line 1



-- 
Edit bug report at https://bugs.php.net/bug.php?id=60725&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60725&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60725&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60725&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60725&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60725&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60725&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60725&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60725&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60725&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60725&r=support
Expected behavior:   
https://bug

[PHP-BUG] Bug #60724 [NEW]: Includes fails at compile time when using bracketed namespaces

2012-01-12 Thread nicolas dot grekas+php at gmail dot com

From: 
Operating system: 
PHP version:  5.4.0RC5
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Includes fails at compile time when using bracketed namespaces

Description:

Tested in 5.3.8, 5.2.9 and 5.4RC5, APC not enabled.

At compile time, two nested includes fail when both use bracketed
namespaces or mix bracketed and unbracketed ones.

The compile time behavior of PHP is described in:
https://bugs.php.net/bug.php?id=42098

I found a workaround that makes me think that some internal state is not
initialized correctly when using namespaces.

See test script for more details.

Test script:
---
https://bugs.php.net/bug.php?id=60724&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60724&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60724&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60724&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60724&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60724&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60724&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60724&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60724&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60724&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60724&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60724&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60724&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60724&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60724&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60724&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60724&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60724&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60724&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60724&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60724&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60724&r=mysqlcfg

Bug #60699 [Opn->Fbk]: mysqli_init() crashes under high concurrency

2012-01-12 Thread pajoye

Edit report at https://bugs.php.net/bug.php?id=60699&edit=1

 ID: 60699
 Updated by: paj...@php.net
 Reported by:ninzya at inbox dot lv
 Summary:mysqli_init() crashes under high concurrency
-Status: Open
+Status: Feedback
 Type:   Bug
-Package:Reproducible crash
+Package:MySQLi related
 Operating System:   Windows 7
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Please keep the category so that the mysql team knows about it.


Previous Comments:

[2012-01-12 08:04:03] ninzya at inbox dot lv

Changed from "MySQLi" to "Reproducible crash" so that more attention is paid to 
this issue.


[2012-01-10 11:45:44] ninzya at inbox dot lv

Description:

Calling purely mysqli_init() crashes PHP under high concurrency.

Using VC9 x86 Thread Safe (2012-Jan-06 02:06:02) build of PHP 5.4.0RC5.
Using Apache HTTPd 2.2.21.0.
Using ab (apache benchmark) tool to simulate high loads: "ab -c 30 -n 2000 
http://localhost:8080/index.php";.

PHP installed as module.

Test script:
---
mysqli_init();

Expected result:

No crash

Actual result:
--
Crash






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60699&edit=1

[PHP-BUG] Bug #60723 [NEW]: error_log error time has changed to UTC ignoring default timezo

2012-01-12 Thread olemarkus at gentoo dot org

From: 
Operating system: Gentoo Linux
PHP version:  5.3.9
Package:  *General Issues
Bug Type: Bug
Bug description:error_log error time has changed to UTC ignoring default timezo

Description:

PHP error log no longer respects timezone and always logs in UTC.

Setting error_log to a filesystem path and date.default_timezone to e.g 
Europe/Oslo gives the following log lines in 5.3.8:

[12-Jan-2012 10:02:38] PHP Notice:  Undefined variable: foo in 
/home/htdocs/index.php on line 3
[12-Jan-2012 10:02:38] PHP Fatal error:  Call to a member function bar() on
a 
non-object in /home/htdocs/index.php on line 3

While in 5.3.9 you get:

[12-Jan-2012 09:06:00 UTC] PHP Notice:  Undefined variable: foo in 
/home/htdocs/index.php on line 3
[12-Jan-2012 09:06:00 UTC] PHP Fatal error:  Call to a member function
bar() on 
a non-object in /home/htdocs/index.php on line 3

Also see downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=398445


-- 
Edit bug report at https://bugs.php.net/bug.php?id=60723&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60723&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60723&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=60723&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60723&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=60723&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60723&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=60723&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=60723&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=60723&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=60723&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=60723&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=60723&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=60723&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60723&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=60723&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60723&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=60723&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=60723&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=60723&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=60723&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=60723&r=mysqlcfg

Bug #60714 [Opn]: htmlspecialchars() ignore default_charset value

2012-01-12 Thread rasmus

Edit report at https://bugs.php.net/bug.php?id=60714&edit=1

 ID: 60714
 Updated by: ras...@php.net
 Reported by:mahatma at bspu dot unibel dot by
 Summary:htmlspecialchars() ignore default_charset value
 Status: Open
 Type:   Bug
 Package:*Languages/Translation
 Operating System:   linux
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

There was discussion. Simply changing the not-specified case to use the 
default_charset setting would break a lot of code. However, since it is a 
useful 
feature, it is supported through the empty string case as documented at 
http://php.net/htmlspecialchars


Previous Comments:

[2012-01-11 22:50:11] cataphr...@php.net

Yes, there's a BC break in 5.4 in this respect. You can make htmlspecialchars 
use default_charset, but you'd still have to change all the calls to use the 
empty string as charset.

I'm leaving this open for now, as this change was made without any discussion I 
remember.


[2012-01-11 15:38:30] mahatma at bspu dot unibel dot by

Description:

Since default charset changed, I got compatibility problem - htmlspecialchars() 
start to strip cp1251 (or any non-unicode) national symbols and no way to 
change another default charset. But looks like default_charset is provided for 
similar goals (and, ideally - charset= html detection too).

I suggest just to get default charset for htmlspecialchars() (and IMHO for 
htmlentities()) from default_charset.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60714&edit=1

Bug #60699 [Opn]: mysqli_init() crashes under high concurrency

2012-01-12 Thread ninzya at inbox dot lv

Edit report at https://bugs.php.net/bug.php?id=60699&edit=1

 ID: 60699
 User updated by:ninzya at inbox dot lv
 Reported by:ninzya at inbox dot lv
 Summary:mysqli_init() crashes under high concurrency
 Status: Open
 Type:   Bug
-Package:MySQLi related
+Package:Reproducible crash
 Operating System:   Windows 7
 PHP Version:5.4.0RC5
 Block user comment: N
 Private report: N

 New Comment:

Changed from "MySQLi" to "Reproducible crash" so that more attention is paid to 
this issue.


Previous Comments:

[2012-01-10 11:45:44] ninzya at inbox dot lv

Description:

Calling purely mysqli_init() crashes PHP under high concurrency.

Using VC9 x86 Thread Safe (2012-Jan-06 02:06:02) build of PHP 5.4.0RC5.
Using Apache HTTPd 2.2.21.0.
Using ab (apache benchmark) tool to simulate high loads: "ab -c 30 -n 2000 
http://localhost:8080/index.php";.

PHP installed as module.

Test script:
---
mysqli_init();

Expected result:

No crash

Actual result:
--
Crash






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60699&edit=1

39 matches

Mail list logo