Bug #53948 [Com]: ZIP archive UTF-8 filenames problem
Edit report at http://bugs.php.net/bug.php?id=53948edit=1
ID: 53948
Comment by: mikhail dot v dot gavrilov at gmail dot com
Reported by:asaf at lingnu dot com
Summary:ZIP archive UTF-8 filenames problem
Status: Duplicate
Type: Bug
Package:Zip Related
Operating System: linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I also confirm this problem.
Workaround: Helps converting to your DOS encoding.
Previous Comments:
[2011-02-18 14:02:20] paj...@php.net
#51929
[2011-02-07 14:06:39] asaf at lingnu dot com
Description:
when creating zip archive with non-english filenames,
the filenames are not encoded correctly, upon extraction
you get them like ???_???.txt.
(tested with various unzipping software on windows/linux)
a suggested workaround, e.g:
$zip-addFile($file_data['path'], iconv(UTF-8,CP852,$file_name));
doesn't help
Test script:
---
?php
$zip = new ZipArchive();
if ($zip-open('/tmp/test.zip', ZIPARCHIVE::CREATE) === TRUE) {
$zip-addFile('/tmp/file.txt', 'ק×××¥.txt');
$zip-close();
echo done;
} else {
echo failed;
}
?
Expected result:
create a zip file which can be extracted reproducing the original file
names.
Actual result:
--
non english file names comes out corrupted, e.g: ???_???.txt
--
Edit this bug report at http://bugs.php.net/bug.php?id=53948edit=1
Bug #51929 [Com]: Extracted a zip file that contains a folder named with Chinese characters
Edit report at http://bugs.php.net/bug.php?id=51929edit=1
ID: 51929
Comment by: mikhail dot v dot gavrilov at gmail dot com
Reported by:kgo_yoi at hotmail dot com
Summary:Extracted a zip file that contains a folder named
with Chinese characters
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows XP Simplified Chinese
PHP Version:5.2.13
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I also confirm this problem.
Workaround: Helps converting to your DOS encoding.
Previous Comments:
[2011-02-18 14:05:12] paj...@php.net
At some point the library will support UTF-8 (as zip specs allow that).
But it is
not yet implemented.
[2011-02-18 14:04:29] paj...@php.net
the library does nothing but to take the names you give as inputs.
The problem is also visible when a zip archive contains entries namend
using UTF-8
or other random encoding. These names are used to the filesystem APIs,
which
expect string endonded using the active run time CP.
[2011-02-18 13:58:12] g dot faust at tarent dot de
Like Bug #53948 (ZIP archive UTF-8 filenames problem) the problem seems
to be the zip-implementation which (seems to) expects CP437 as valid
encoding for file-/foldernames.
using
$newFileOrFoldername = iconv('UTF-8', 'CP437//IGNORE//TRANSLIT',
$oldFileOrFoldername);
as a Workaround, you have to look that iconv() supports CP437.
After this Workaround it works* with Win7(64bit) and Ubuntu 10.4(64bit)
but the Archivemanager under Ubuntu 10.4(32bit) still shows wrong
characters.
*) With the converted Filename where characters not-matching CP437 will
be transliterated or even ignored - so it may be not a Workaround for
Chinese characters ...
[2010-05-27 13:36:22] kgo_yoi at hotmail dot com
Description:
Extracted a zip file contains a folder named with Chinese characters,
the files in the folder is no longer in it.
e.g.
I have 2 zips, the one named en.zip contains a folder named English
en.zip
|- English
|- en.txt
the other named zh.zip contains a folder named ä¸æ
zh.zip
|- ä¸æ
|- zh.txt
Then I use ZipArchive to extract them,
Test script:
---
?php
$zip = new ZipArchive;
$zip-open('en.zip');
$zip-extractTo('.');
$zip-close();
$zip-open('zh.zip');
$zip-extractTo('.');
$zip-close();
Expected result:
There are 2 folders, 'English' and 'ä¸æ', each folder contains a txt
file.
Actual result:
--
The 'English' folder contains a txt file named en.txt; the 'ä¸æ'
folder is empty and zh.txt is out of it.
--
Edit this bug report at http://bugs.php.net/bug.php?id=51929edit=1
Bug #54947 [Opn-Bgs]: ssh2.sftp protocol wrapper works incorrectly for paths which contain a '#'
Edit report at http://bugs.php.net/bug.php?id=54947edit=1 ID: 54947 Updated by: paj...@php.net Reported by:josvanbakel at gmail dot com Summary:ssh2.sftp protocol wrapper works incorrectly for paths which contain a '#' -Status: Open +Status: Bogus Type: Bug Package:*Network Functions Operating System: Ubuntu PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Please report ssh2 bugs to pecl.php.net/ssh2. Also it could be a problem in libssh2 itself, I will have to check. Previous Comments: [2011-05-29 19:59:34] josvanbakel at gmail dot com Thanks for the tip. I'll give it a try. [2011-05-29 16:53:37] zelnaga at gmail dot com You'd probably have more success with phpseclib, a pure PHP SFTP implementation: http://phpseclib.sourceforge.net/ Doesn't absolve the maintainer of the php_ssh2.dll from fixing this bug but it's a work around you can none-the-less use until the problem is fixed. [2011-05-28 15:42:31] josvanbakel at gmail dot com Description: When trying to read a file or directory via the ssh2.sftp protocol wrapper which contains a '#' in the path ssh2.sftp will ignore it. It looks like it treats the '#' as a start comment command (e.g. // in PHP) In the test script, i have used the following directory structure: #Test/ a Test#/ b Test/ c Note that creating the directories from the bash shell requires escaping the # with a \, e.g.: mkdir \#Test Test script: --- // $sftp is a ssh2_sftp resource // $dir is the directory containing the test directory structure (see description) $root = ssh2.sftp://$sftp/$dir;; $a = scandir($root/#Test); // $a = array(., .., #Test, Test#, Test); // Note that $a is a dir listing of $root, everything after the # is ignored $b = scandir($root/Test#); // $b = array(., .., c); // Gives a listing of Test not of Test# Expected result: $a = array(., .., a); $b = array(., .., b); Actual result: -- $a = array(., .., #Test, Test#, Test); $b = array(., .., c); -- Edit this bug report at http://bugs.php.net/bug.php?id=54947edit=1
[PHP-BUG] Bug #54952 [NEW]: Finfo invalid mime type detect for webm format
From:
Operating system: Debian 6 32bit
PHP version: 5.3.6
Package: Filesystem function related
Bug Type: Bug
Bug description:Finfo invalid mime type detect for webm format
Description:
Finfo extention detects invalid mime type for webm video format.
application/octet-stream; charset=binary instead of video/webm
Test script:
---
?php
$f = new finfo();
echo $f-file('MyVideo.webm',FILEINFO_MIME); // outputs
application/octet-stream; charset=binary but should be video/webm
Expected result:
video/webm
Actual result:
--
application/octet-stream; charset=binary
--
Edit bug report at http://bugs.php.net/bug.php?id=54952edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54952r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54952r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54952r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54952r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54952r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54952r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54952r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54952r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54952r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54952r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54952r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54952r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54952r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54952r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54952r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54952r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54952r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54952r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54952r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54952r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54952r=mysqlcfg
Bug #54952 [Opn-Bgs]: Finfo invalid mime type detect for webm format
Edit report at http://bugs.php.net/bug.php?id=54952edit=1
ID: 54952
Updated by: il...@php.net
Reported by:daniel at bojdo dot eu
Summary:Finfo invalid mime type detect for webm format
-Status: Open
+Status: Bogus
Type: Bug
Package:Filesystem function related
Operating System: Debian 6 32bit
PHP Version:5.3.6
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.
The issue is with the libmagic library which is the one responsible for
file type
detection.
Previous Comments:
[2011-05-30 11:05:45] daniel at bojdo dot eu
Description:
Finfo extention detects invalid mime type for webm video format.
application/octet-stream; charset=binary instead of video/webm
Test script:
---
?php
$f = new finfo();
echo $f-file('MyVideo.webm',FILEINFO_MIME); // outputs
application/octet-stream; charset=binary but should be video/webm
Expected result:
video/webm
Actual result:
--
application/octet-stream; charset=binary
--
Edit this bug report at http://bugs.php.net/bug.php?id=54952edit=1
[PHP-BUG] Bug #54953 [NEW]: Implements SPL Interfaces wont work on mapped classes
From:
Operating system: n/a
PHP version: 5.3.6
Package: SOAP related
Bug Type: Bug
Bug description:Implements SPL Interfaces wont work on mapped classes
Description:
If you implement the Iterator interface on one of the classes that you use
in the
classmap that you pass to SoapClient::SoapClient(), it does not work. If
you use
foreach() on the object that implements the interface it just iterates of
the
properties of the object instead of using the custom iterator you
implemented.
Test script:
---
Not a full working code since this requires a SOAP service, but this gives
you the gist:
class Bar implements Iterator { /*...*/ }
$bar = $soapClient-someFunc() // say this is an object returned by a SOAP
client call and was mapped to class Bar
foreach ($bar as $key = $value) {
// Just iterates over each property
}
$baz = new Bar();
foreach ($baz as $key = $value) {
// Works as expected
}
Expected result:
I expect the custom iterator to be used when I iterator over an object
returned by
the SOAPClient.
Actual result:
--
Custom iterator is ignored, I get just regular iteration over all
properties of
the class Bar.
--
Edit bug report at http://bugs.php.net/bug.php?id=54953edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54953r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54953r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54953r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54953r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54953r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54953r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54953r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54953r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54953r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54953r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54953r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54953r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54953r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54953r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54953r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54953r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54953r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54953r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54953r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54953r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54953r=mysqlcfg
Bug #54953 [Opn]: Implemented SPL Interfaces wont work on mapped classes
Edit report at http://bugs.php.net/bug.php?id=54953edit=1
ID: 54953
User updated by:willem dot stuursma at hyves dot nl
Reported by:willem dot stuursma at hyves dot nl
-Summary:Implements SPL Interfaces wont work on mapped
classes
+Summary:Implemented SPL Interfaces wont work on mapped
classes
Status: Open
Type: Bug
Package:SOAP related
Operating System: n/a
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
(corrected typo in bug title)
Previous Comments:
[2011-05-30 14:44:28] willem dot stuursma at hyves dot nl
Description:
If you implement the Iterator interface on one of the classes that you
use in the
classmap that you pass to SoapClient::SoapClient(), it does not work. If
you use
foreach() on the object that implements the interface it just iterates
of the
properties of the object instead of using the custom iterator you
implemented.
Test script:
---
Not a full working code since this requires a SOAP service, but this
gives you the gist:
class Bar implements Iterator { /*...*/ }
$bar = $soapClient-someFunc() // say this is an object returned by a
SOAP client call and was mapped to class Bar
foreach ($bar as $key = $value) {
// Just iterates over each property
}
$baz = new Bar();
foreach ($baz as $key = $value) {
// Works as expected
}
Expected result:
I expect the custom iterator to be used when I iterator over an object
returned by
the SOAPClient.
Actual result:
--
Custom iterator is ignored, I get just regular iteration over all
properties of
the class Bar.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54953edit=1
Bug #40048 [Com]: SQL IN (...) and = ANY (...) not supported by PDO
Edit report at http://bugs.php.net/bug.php?id=40048edit=1
ID: 40048
Comment by: ggrraay at gmail dot com
Reported by:bugs dot php dot net at andrewprendergast dot com
Summary:SQL IN (...) and = ANY (...) not supported by PDO
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Linux Red Hat EL
PHP Version:5.2.1RC2
Block user comment: N
Private report: N
New Comment:
PDO does not implement query parsing it is entirely up to the
database.
Query parsing not needed, it can be done this way
$stmt = $dbh-prepare(SELECT * FROM table WHERE id IN(:ids));
$sth-bindValue(':ids', array(1,2,3), PDO::PARAM_ARRAY);
If specified PDO::PARAM_ARRAY in bindValue method query can be parsed as
this
SELECT * FROM table WHERE id IN(1,2,3)
not as
SELECT * FROM table WHERE id IN('1,2,3')
The solution is to re-write queries to use IN (?, ?, �)
It will not work if parameters array has variable length
Previous Comments:
[2007-01-08 00:23:49] bugs dot php dot net at andrewprendergast dot com
Just to re-iterate some comments made about this on IRC:
ilia again PDO is not design to modify or extend SQL query language
Pierre about definition, PDO is only a wrapper not an abstraction
layer, it does not abstract anything (besides
Specifically PDO does not do any parsing of SQL queries, it just passes
them directly to the database engine in question so PDO is unable to
re-write the SQL to support this feature.
The solution is to re-write queries to use IN (?, ?,
)
[2007-01-07 23:46:51] nlop...@php.net
I also came across this problem last week: it would be could if we could
bind an array to IN(). Probably it would be too dificult, but we could
support this syntax in our sql re2c lexer..
[2007-01-07 17:44:11] il...@php.net
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.
PDO does not implement query parsing it is entirely up to the
database. So the features you are talking about would only
work if supported by the underlying database.
[2007-01-07 13:35:55] bugs dot php dot net at andrewprendergast dot com
Description:
PDO doesn't allow one to SELECT or DELETE groups of records
based on their primary key.
Specifically, the SQL clauses WHERE ... IN (...) and WHERE ... = ANY
(...) does not work for more than one record.
As a workaround I can construct an SQL query and execute it myself but
that defeats the niceness of PDO.
Reproduce code:
---
the following should return the records with ID 1 2:
$dbh = new PDO('mysql:host=localhost;dbname=mobop', root, );
$stmt = $dbh-prepare(SELECT * FROM news_item WHERE news_item_id
IN(?));
if ( $stmt-execute(array(1, 2)) )
while ( ($row = $stmt-fetch()) )
print_r($row);
But it doesn't.
The following execute statement fails as well:
$stmt-execute(array(array(2,1)))
NB: The intention of the 2nd example is that when binding an array, it
seems natural that PDO would assume its part of an IN or =ANY clause and
convert it into a bunch of comma separated keys automagically. Some of
the higher level PDO based O/R abstractions currently bouncing around
like Doctrine would then be able to support (without any modificaiton)
queries that affect multiple records.
Expected result:
Two records should be loaded.
Actual result:
--
One record is loaded.
--
Edit this bug report at http://bugs.php.net/bug.php?id=40048edit=1
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832edit=1 ID: 54832 Comment by: neweracracker at gmail dot com Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revisionrevision=310691 Thank you. Previous Comments: [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug [2011-05-26 14:50:06] johan...@php.net This works on other systems quite well. Are you sure you have no firewall or such? Pleas etry using 127.0.0.1 instead of localhost (there had been issues due to Ipv6 vs. IPv4 in the past) [2011-05-21 21:33:41] giorgio dot liscio at email dot it same error on latest 5.4 revision too May 21 2011 20:50:15 i'm using the binaries of windows.php.net http://windows.php.net/downloads/snaps/php-5.4/r311300/ 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 http://bugs.php.net/bug.php?id=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832edit=1
Bug #52496 [Opn-Csd]: Zero exit code on option parsing failure
Edit report at http://bugs.php.net/bug.php?id=52496edit=1 ID: 52496 Updated by: il...@php.net Reported by:php-bugs at thequod dot de Summary:Zero exit code on option parsing failure -Status: Open +Status: Closed Type: Bug Package:CGI related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-05-30 17:57:53] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=311600 Log: Fixed bug #52496 (Zero exit code on option parsing failure). [2010-07-30 08:36:00] php-bugs at thequod dot de Description: When PHP's option parsing fails, PHP outputs the Usage info, but exits with exit code 0, which means success. So, given any PHP script where the options in the shebang line are wrong, or only considered wrong (like with bug 52495), will never execute, but always report success! Please fix this, so that option parsing will return a non-exit error code. Test script: --- # php --wrong-option ; echo $? Expected result: # php --wrong-option ; echo $? Usage: php [options] [-f] file [--] [args...] [...] 1 Actual result: -- # php --wrong-option ; echo $? Usage: php [options] [-f] file [--] [args...] [...] 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=52496edit=1
Bug #54710 [Opn-Bgs]: sys_get_temp_dir() does not respect upload_tmp_dir
Edit report at http://bugs.php.net/bug.php?id=54710edit=1 ID: 54710 Updated by: il...@php.net Reported by:royanee at yahoo dot com Summary:sys_get_temp_dir() does not respect upload_tmp_dir -Status: Open +Status: Bogus Type: Bug Package:PHP options/info functions PHP Version:5.3.6 Block user comment: N Private report: N New Comment: 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 The function is designed to return the location of the temporary directory, not the file upload directory. Previous Comments: [2011-05-11 15:47:13] royanee at yahoo dot com Additionally, enabling open_basedir results in FALSE and triggers the following warning: PHP Warning: tempnam(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/www/myvhost/) [2011-05-11 15:45:07] royanee at yahoo dot com Description: The only configuration option for setting the temporary directory for normal operations is the upload_tmp_dir option. As such, functions that rely on the temporary directory should respect the upload_tmp_dir option to ensure that true separation of concerns between virtual hosts can be achieved. This is particularly important when also using open_basedir. Note that the following line is correctly located in the vhost config: php_admin_value upload_tmp_dir /www/myvhost/tmp Test script: --- ?php // Create a temporary file in the temporary // files directory using sys_get_temp_dir() $temp_file = tempnam(sys_get_temp_dir(), 'Tux'); echo $temp_file; ? Expected result: /www/myvhost/tmp/TuxDRhRIg Actual result: -- /tmp/TuxDRhRIg -- Edit this bug report at http://bugs.php.net/bug.php?id=54710edit=1
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832edit=1 ID: 54832 Comment by: giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: can you reproduce the problem? Previous Comments: [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revisionrevision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug [2011-05-26 14:50:06] johan...@php.net This works on other systems quite well. Are you sure you have no firewall or such? Pleas etry using 127.0.0.1 instead of localhost (there had been issues due to Ipv6 vs. IPv4 in the past) 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 http://bugs.php.net/bug.php?id=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832edit=1
[PHP-BUG] Bug #54955 [NEW]: FastCGI doesn't recognize Windows relative paths
From: Operating system: Windows 7 64bits SP1 PHP version: 5.3.6 Package: CGI related Bug Type: Bug Bug description:FastCGI doesn't recognize Windows relative paths Description: I have configured my webserver (nginx) to have its document root out of its working path in ..\files (please, note the two dots). When I request static files, it serves them without any problem. Anyway If I request a PHP file, the request it's not served because php-cgi.exe running as the fastCGI server al 127.0.0.1:9000 returns an error 400 code. If I user absolute paths it works. Also, if I move the ..\files folder to ./files (please, note the only one dot) and I change the document root to reflect that new relative path. So It looks that relative paths with two dots are not getting resolved by php- cgi.exe as fastCGI server. -- Edit bug report at http://bugs.php.net/bug.php?id=54955edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54955r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54955r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54955r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54955r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54955r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54955r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54955r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54955r=needscript Try newer version: http://bugs.php.net/fix.php?id=54955r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54955r=support Expected behavior: http://bugs.php.net/fix.php?id=54955r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54955r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54955r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54955r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54955r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54955r=dst IIS Stability: http://bugs.php.net/fix.php?id=54955r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54955r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54955r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54955r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54955r=mysqlcfg
Bug #44780 [Com]: some time zone offsets not recognized by timezone_name_from_abbr
Edit report at http://bugs.php.net/bug.php?id=44780edit=1
ID: 44780
Comment by: theogaden at gmail dot com
Reported by:shawn dot parker at alttech dot com
Summary:some time zone offsets not recognized by
timezone_name_from_abbr
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5CVS-2008-08-14
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I have the exact same problem and I found this bug entry thanks to
someone at
stackoverflow. Here was my original question:
http://stackoverflow.com/questions/6180892/why-does-timezone-name-from-abbr-
return-an-empty-string
Test Code
--
$offset = -10; //UM10
echo timezone_name_from_abbr('', $offset * 3600, true); //empty string
Expected Result
--
Pacific/Honolulu
Actual result:
--
false
I am using PHP 5.3.0.
Previous Comments:
[2009-05-08 18:23:40] mfburdett at gmail dot com
I was able to resolve this by changing the fallbackmap from hours to
minutes (the bug is apparently due to some issue with float vs.
integer). Also, this patch adds Caracas and Shanghai time (there are
likely other missing time zones, however) and uses the new spelling for
Calcutta (Kolkata).
Index: ext/date/lib/fallbackmap.h
===
RCS file: /repository/php-src/ext/date/lib/fallbackmap.h,v
retrieving revision 1.3
diff -u -p -r1.3 fallbackmap.h
--- ext/date/lib/fallbackmap.h 15 Oct 2005 18:14:40 - 1.3
+++ ext/date/lib/fallbackmap.h 8 May 2009 18:18:32 -
@@ -1,40 +1,42 @@
- { sst, 0, -11, Pacific/Apia },
- { hst, 0, -10, Pacific/Honolulu },
- { akst, 0, -9, America/Anchorage },
- { akdt, 1, -8, America/Anchorage },
- { pst, 0, -8, America/Los_Angeles },
- { pdt, 1, -7, America/Los_Angeles },
- { mst, 0, -7, America/Denver },
- { mdt, 1, -6, America/Denver },
- { cst, 0, -6, America/Chicago },
- { cdt, 1, -5, America/Chicago },
- { est, 0, -5, America/New_York },
- { edt, 1, -4, America/New_York },
- { ast, 0, -4, America/Halifax },
- { adt, 1, -3, America/Halifax },
- { brt, 0, -3, America/Sao_Paulo },
- { brst, 1, -2, America/Sao_Paulo },
- { azost, 0, -1, Atlantic/Azores },
- { azodt, 1,0, Atlantic/Azores },
- { gmt, 0,0, Europe/London },
- { bst, 1,1, Europe/London },
- { cet, 0,1, Europe/Paris },
- { cest, 1,2, Europe/Paris },
- { eet, 0,2, Europe/Helsinki },
- { eest, 1,3, Europe/Helsinki },
- { msk, 0,3, Europe/Moscow },
- { msd, 1,4, Europe/Moscow },
- { gst, 0,4, Asia/Dubai },
- { pkt, 0,5, Asia/Karachi },
- { ist, 0, 5.5, Asia/Calcutta },
- { npt, 0, 5.75, Asia/Katmandu },
- { yekt, 1,6, Asia/Yekaterinburg },
- { novst, 1,7, Asia/Novosibirsk },
- { krat, 0,7, Asia/Krasnoyarsk },
- { krast, 1,8, Asia/Krasnoyarsk },
- { jst, 0,9, Asia/Tokyo },
- { est, 0, 10, Australia/Melbourne },
- { cst, 1, 10.5, Australia/Adelaide },
- { est, 1, 11, Australia/Melbourne },
- { nzst, 0, 12, Pacific/Auckland },
- { nzdt, 1, 13, Pacific/Auckland },
+ { sst, 0, -660, Pacific/Apia },
+ { hst, 0, -600, Pacific/Honolulu },
+ { akst, 0, -540, America/Anchorage },
+ { akdt, 1, -480, America/Anchorage },
+ { pst, 0, -480, America/Los_Angeles },
+ { pdt, 1, -420, America/Los_Angeles },
+ { mst, 0, -420, America/Denver },
+ { mdt, 1, -360, America/Denver },
+ { cst, 0, -360, America/Chicago },
+ { cdt, 1, -300, America/Chicago },
+ { est, 0, -300, America/New_York },
+ { vet, 0, -270, America/Caracas },
+ { edt, 1, -240, America/New_York },
+ { ast, 0, -240, America/Halifax },
+ { adt, 1, -180, America/Halifax },
+ { brt, 0, -180, America/Sao_Paulo },
+ { brst, 1, -120, America/Sao_Paulo },
+ { azost, 0, -60, Atlantic/Azores },
+ { azodt, 1,0, Atlantic/Azores },
+ { gmt, 0,0, Europe/London },
+ { bst, 1, 60, Europe/London },
+ { cet, 0, 60, Europe/Paris },
+ { cest, 1, 120, Europe/Paris },
+ { eet, 0, 120, Europe/Helsinki },
+ { eest, 1, 180, Europe/Helsinki },
+ { msk, 0, 180, Europe/Moscow },
+ { msd, 1, 240, Europe/Moscow },
+
[PHP-BUG] Bug #54957 [NEW]: Memleak in alloc_globals_ctor
From: felipe Operating system: PHP version: trunk-SVN-2011-05-30 (SVN) Package: Scripting Engine problem Bug Type: Bug Bug description:Memleak in alloc_globals_ctor Description: A memory leak happens when using ZTS+USE_ZEND_ALLOC=0 Test script: --- $ USE_ZEND_ALLOC=0 valgrind --tool=memcheck --leak-check=yes sapi/cli/php -v ==17712== Memcheck, a memory error detector ==17712== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17712== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==17712== Command: sapi/cli/php -v ==17712== PHP 5.5.0-dev (cli) (built: May 30 2011 18:37:59) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies ==17712== ==17712== HEAP SUMMARY: ==17712== in use at exit: 604 bytes in 1 blocks ==17712== total heap usage: 19,354 allocs, 19,353 frees, 1,466,000 bytes allocated ==17712== ==17712== 604 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==17712==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==17712==by 0x8429867: alloc_globals_ctor (zend_alloc.c:2633) ==17712==by 0x83C103F: ts_allocate_id (TSRM.c:255) ==17712==by 0x8429917: start_memory_manager (zend_alloc.c:2654) ==17712==by 0x845D1A4: zend_startup (zend.c:642) ==17712==by 0x83C893A: php_module_startup (main.c:1901) ==17712==by 0x85A479B: php_cli_startup (php_cli.c:414) ==17712==by 0x85A567B: main (php_cli.c:790) ==17712== ==17712== LEAK SUMMARY: ==17712==definitely lost: 604 bytes in 1 blocks ==17712==indirectly lost: 0 bytes in 0 blocks ==17712== possibly lost: 0 bytes in 0 blocks ==17712==still reachable: 0 bytes in 0 blocks ==17712== suppressed: 0 bytes in 0 blocks ==17712== ==17712== For counts of detected and suppressed errors, rerun with: -v ==17712== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 9) -- Edit bug report at http://bugs.php.net/bug.php?id=54957edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54957r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54957r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54957r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54957r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54957r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54957r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54957r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54957r=needscript Try newer version: http://bugs.php.net/fix.php?id=54957r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54957r=support Expected behavior: http://bugs.php.net/fix.php?id=54957r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54957r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54957r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54957r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54957r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54957r=dst IIS Stability: http://bugs.php.net/fix.php?id=54957r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54957r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54957r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54957r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54957r=mysqlcfg
Bug #54957 [Opn-Asn]: Memleak in alloc_globals_ctor
Edit report at http://bugs.php.net/bug.php?id=54957edit=1 ID: 54957 Updated by: fel...@php.net Reported by:fel...@php.net Summary:Memleak in alloc_globals_ctor -Status: Open +Status: Assigned Type: Bug Package:Scripting Engine problem -PHP Version:trunk-SVN-2011-05-30 (SVN) +PHP Version:5.4, trunk -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2011-05-31 01:56:03] fel...@php.net Description: A memory leak happens when using ZTS+USE_ZEND_ALLOC=0 Test script: --- $ USE_ZEND_ALLOC=0 valgrind --tool=memcheck --leak-check=yes sapi/cli/php -v ==17712== Memcheck, a memory error detector ==17712== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==17712== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==17712== Command: sapi/cli/php -v ==17712== PHP 5.5.0-dev (cli) (built: May 30 2011 18:37:59) (DEBUG) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies ==17712== ==17712== HEAP SUMMARY: ==17712== in use at exit: 604 bytes in 1 blocks ==17712== total heap usage: 19,354 allocs, 19,353 frees, 1,466,000 bytes allocated ==17712== ==17712== 604 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==17712==at 0x4023F50: malloc (vg_replace_malloc.c:236) ==17712==by 0x8429867: alloc_globals_ctor (zend_alloc.c:2633) ==17712==by 0x83C103F: ts_allocate_id (TSRM.c:255) ==17712==by 0x8429917: start_memory_manager (zend_alloc.c:2654) ==17712==by 0x845D1A4: zend_startup (zend.c:642) ==17712==by 0x83C893A: php_module_startup (main.c:1901) ==17712==by 0x85A479B: php_cli_startup (php_cli.c:414) ==17712==by 0x85A567B: main (php_cli.c:790) ==17712== ==17712== LEAK SUMMARY: ==17712==definitely lost: 604 bytes in 1 blocks ==17712==indirectly lost: 0 bytes in 0 blocks ==17712== possibly lost: 0 bytes in 0 blocks ==17712==still reachable: 0 bytes in 0 blocks ==17712== suppressed: 0 bytes in 0 blocks ==17712== ==17712== For counts of detected and suppressed errors, rerun with: -v ==17712== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 34 from 9) -- Edit this bug report at http://bugs.php.net/bug.php?id=54957edit=1
Bug #51176 [Com]: Static calling in non-static method behaves like $this-
Edit report at http://bugs.php.net/bug.php?id=51176edit=1 ID: 51176 Comment by: david71rj at gmail dot com Reported by:majkl578 at gmail dot com Summary:Static calling in non-static method behaves like $this- Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:5.3.2RC3 Assigned To:felipe Block user comment: N Private report: N New Comment: Sorry by realive this topic, but I really think that it is a bug. If I want call bar with context, the correct mean is $this-bar(). Else, the static sounds for me like call without context. I'm wrong? Please, read this topic to understand what I'm saying: http://stackoverflow.com/questions/6181603/php-is-handling-incorrectly-my-static- call Previous Comments: [2010-11-03 12:03:17] majkl578 at gmail dot com You cannot call foo::start(), because the method is non-static and therefore it does not make sense. Also, self, static and class name are used to call methods statically, not in a object context. For calling method bar in object context, I think '$this-' should be used instead. Obviously parent should not behave this way and respect context, but I think it should be the only exception (as shown in #52713). [2010-11-03 02:45:23] fel...@php.net Hello, I've reverted the wrong changes introduced by trying to fix the issue reported, but actually there is no bug at all. self::bar(), static::bar() and foo::bar() are being called in an object context, hence the __call() is called. I.e. $foo-start(); // invoke the __call method foo::start(); // invoke the __callStatic method Thanks. [2010-11-03 02:35:28] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305043 Log: - Reverted fix for bug #51176 [2010-03-04 14:27:55] fel...@php.net Hello! This isn't my decision, but the release manager. Thanks. [2010-03-04 12:33:59] majkl578 at gmail dot com Can you explain me, please, why this is not fixed in 5.3.2 stable? Thank you for the report, and for helping us make PHP better. You are intentionally making PHP worse! 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 http://bugs.php.net/bug.php?id=51176 -- Edit this bug report at http://bugs.php.net/bug.php?id=51176edit=1
Bug #54832 [Com]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832edit=1 ID: 54832 Comment by: neweracracker at gmail dot com Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql Status: Open Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev Block user comment: N Private report: N New Comment: Yes. I can reproduce the problem. I am sure devs will fix then when they have time available. Previous Comments: [2011-05-30 21:28:38] giorgio dot liscio at email dot it can you reproduce the problem? [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revisionrevision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) [2011-05-26 14:57:27] giorgio dot liscio at email dot it hi johannes, i tested with every combination, including firewall issues but updating php latest revisions i noticed that not always driver throws that error sometimes on a just ran server (or thread?) some queries work, and sometimes when i F5 my browser the same queries continue to work, but if i hold down f5 for a lot of continuous reloads the error HY000/2002 is thrown hope this helps to fix the bug 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 http://bugs.php.net/bug.php?id=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832edit=1
Bug #54896 [Opn-Ctl]: Connection to localhost doesn't work in Apache SAPI but works in CLI and CGI
Edit report at http://bugs.php.net/bug.php?id=54896edit=1
ID: 54896
Updated by: paj...@php.net
Reported by:neweracracker at gmail dot com
Summary:Connection to localhost doesn't work in Apache SAPI
but works in CLI and CGI
-Status: Open
+Status: Critical
Type: Bug
Package:Streams related
Operating System: Windows 7
PHP Version:5.3SVN-2011-05-20 (snap)
-Assigned To:
+Assigned To:cataphract
Block user comment: N
Private report: N
New Comment:
Gustavo, pls check this out as well.
Previous Comments:
[2011-05-24 18:31:40] neweracracker at gmail dot com
This bug seems to be a consequence of bug #54918
It works flawless prior to this commit
svn.php.net/viewvc?view=revisionrevision=310691
[2011-05-21 00:55:40] neweracracker at gmail dot com
Description:
I have downloaded a snapshot of php 5.3.7 (Revision: 311276) from
windows.php.net/snapshots/ and I am using php.ini-production as my
php.ini file
IPv6 is enabled in my machine.
Using Apache and running the test script I got bool(false)
Using nginx (with php fastcgi) and running the test script I got
resource(1) of type (stream)
Running php from the cmd line and running the test script I got
resource(4) of type (stream)
I think it is supposed to work with all situations.
Please attempt to reproduce and fix this bug.
Thank you.
Test script:
---
?php
var_dump( @fsockopen('localhost',80) );
?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54896edit=1
Bug #54832 [Opn-Ctl]: unable to connect to mysql
Edit report at http://bugs.php.net/bug.php?id=54832edit=1 ID: 54832 Updated by: paj...@php.net Reported by:giorgio dot liscio at email dot it Summary:unable to connect to mysql -Status: Open +Status: Critical Type: Bug Package:MySQL related Operating System: windows 7 x64 ultimate PHP Version:5.4.0-dev -Assigned To: +Assigned To:cataphract Block user comment: N Private report: N New Comment: Pls check this one as well, regression introduced by the browswer fix (wondering what can cause that in mysql/socket code.) Previous Comments: [2011-05-31 02:21:07] neweracracker at gmail dot com Yes. I can reproduce the problem. I am sure devs will fix then when they have time available. [2011-05-30 21:28:38] giorgio dot liscio at email dot it can you reproduce the problem? [2011-05-30 17:19:09] neweracracker at gmail dot com Hello, There is a similar bug: bug #54896 It is related to this commit svn.php.net/viewvc?view=revisionrevision=310691 Thank you. [2011-05-26 16:47:40] giorgio dot liscio at email dot it yes i've tried with 127.0.0.1 wireshark can't capture localhost packets due to a windows limitation :rage: i have to try in my network, i will update you thank you [2011-05-26 15:53:43] johan...@php.net Have you tried 127.0.0.1 instead of localhost? Or are you actually connecting to a remote host? As mentioned in my previous statement we had such timeouts due to IPv6 issues in the past. While then it doesn't make sense if it works sometimes ... My next best guess would be to try using a network analyzer (wireshark or such) to log the network traffic. Not sure I have a better idea (while I myself am not to familiar with such low level analysis on windows, maybe there are simpler ways ...) 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 http://bugs.php.net/bug.php?id=54832 -- Edit this bug report at http://bugs.php.net/bug.php?id=54832edit=1
[PHP-BUG] Bug #54959 [NEW]: Report One Bug For 08 And 09 Numbers In functions
From:
Operating system: All
PHP version: 5.3.6
Package: *General Issues
Bug Type: Bug
Bug description:Report One Bug For 08 And 09 Numbers In functions
Description:
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Test script:
---
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Expected result:
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Actual result:
--
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
--
Edit bug report at http://bugs.php.net/bug.php?id=54959edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54959r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54959r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54959r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54959r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54959r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54959r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54959r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54959r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54959r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54959r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54959r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54959r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54959r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54959r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54959r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54959r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54959r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54959r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54959r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54959r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54959r=mysqlcfg
Bug #54959 [Opn-Bgs]: Report One Bug For 08 And 09 Numbers In functions
Edit report at http://bugs.php.net/bug.php?id=54959edit=1
ID: 54959
Updated by: scott...@php.net
Reported by:farszabanan at yahoo dot com
Summary:Report One Bug For 08 And 09 Numbers In functions
-Status: Open
+Status: Bogus
Type: Bug
Package:*General Issues
Operating System: All
PHP Version:5.3.6
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.
Numbers beginning with a 0 are octal numbers.
Previous Comments:
[2011-05-31 07:32:52] farszabanan at yahoo dot com
Description:
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Test script:
---
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Expected result:
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
Actual result:
--
?php
/*
Report One Bug For 08 And 09 Numbers In functions
*/
function test_1($number){echo $number;}
echo test_1(08); // out: 0
echo test_1(8); // out: 8
echo test_1(09); // out: 0
echo test_1(9); // out: 9
/* Only for 08 and 09 _ Example: */
echo test_1(07); // out: 7
echo test_1(7); // out: 7
?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54959edit=1
