Bug #61669 [Opn]: ext\standard\tests\file\rename_variation7-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61669&edit=1 ID: 61669 Updated by: larue...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation7-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: i think is okey to commit this. ;) Previous Comments: [2012-04-08 11:43:16] a...@php.net The following patch has been added/updated: Patch Name: 61669.diff Revision: 1333885396 URL: https://bugs.php.net/patch-display.php?bug=61669&patch=61669.diff&revision=1333885396 [2012-04-08 11:36:58] a...@php.net Description: Test diff: 003+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 12 003- Warning: readlink(): Could not open file (error 2) in %s on line %d 006+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link2), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 13 006- Warning: readlink(): Could not open file (error 2) in %s on line %d fail is php 5.3 only Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61669&edit=1
Bug #61655 [Opn->Nab]: Unable to access key in array cast from object
Edit report at https://bugs.php.net/bug.php?id=61655&edit=1
ID: 61655
Updated by: larue...@php.net
Reported by:phpbugs at deep-freeze dot ca
Summary:Unable to access key in array cast from object
-Status: Open
+Status: Not a bug
Type: Bug
Package:Arrays related
Operating System: RedHat
PHP Version:5.3.10
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
This is a documented behavior, plz lok at:
http://www.php.net/manual/en/language.types.array.php
Fixing that implies a perfomance decrease.
Previous Comments:
[2012-04-09 02:52:20] reeze dot xia at gmail dot com
Hi,
in a object property lookup by name always in string, but in array numeric
string(like "22200" ) key will transform to numeric but not a string anymore.
when conversion internal HashTable did't changed so after conversion, key
lookup will fail.
as you posted:
array(1) {
["804496778"]=>
string(5) "Hello"
}
the key is string but not number.
if you do like this:
$array["1000"] = "value"
var_dump($array);
array(1) {
[1000]=>
string(5) "value"
}
see ? "1000" changed to 1000.
I've post a discussion about this in internal list. http://marc.info/?l=php-
internals&m=133390323614733&w=2
[2012-04-07 08:14:11] googleclone at https dot webasyst dot net
http://www.blackberryempire.com/forum/buysell/single_ad.php?ad_id=6
http://posterous-spaces.posterous.com/
http://googleclone.tumblr.com/
http://googleclone.tumblr.com/
https://profiled.com/mobile/blog
[2012-04-06 23:49:55] phpbugs at deep-freeze dot ca
Description:
Casting from an object to an array with numeric key leaves the element
inaccessible.
Given a object with a field whose name is numeric, after a cast to array, there
is no means to access the element.
That is $array['804496778'] yields an undefined error
array_key_exists(804496778, $array); yields false
array_key_exists('804496778', $array); fields false
yet a var_dump($array); shows this element;
and a array_keys($array); returns array(1) { [0] string(9) "804496778" }
Test script:
---
$object = new stdClass();
$key = '804496778';
$object->{$key} = "Hello;
$array = (array)$object;
echo $array[$key], ' ', (int)array_key_exists($key, $array), PHP_EOL;
var_dump($array)
Expected result:
Hello 1
array(1) {
["804496778"]=>
string(5) "Hello"
}
Actual result:
--
PHP Notice: Undefined index: 804496778 in /home/icewolf/bug.php on line 6
0
array(1) {
["804496778"]=>
string(5) "Hello"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61655&edit=1
Bug #61655 [Com]: Unable to access key in array cast from object
Edit report at https://bugs.php.net/bug.php?id=61655&edit=1
ID: 61655
Comment by: reeze dot xia at gmail dot com
Reported by:phpbugs at deep-freeze dot ca
Summary:Unable to access key in array cast from object
Status: Open
Type: Bug
Package:Arrays related
Operating System: RedHat
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Hi,
in a object property lookup by name always in string, but in array numeric
string(like "22200" ) key will transform to numeric but not a string anymore.
when conversion internal HashTable did't changed so after conversion, key
lookup will fail.
as you posted:
array(1) {
["804496778"]=>
string(5) "Hello"
}
the key is string but not number.
if you do like this:
$array["1000"] = "value"
var_dump($array);
array(1) {
[1000]=>
string(5) "value"
}
see ? "1000" changed to 1000.
I've post a discussion about this in internal list. http://marc.info/?l=php-
internals&m=133390323614733&w=2
Previous Comments:
[2012-04-07 08:14:11] googleclone at https dot webasyst dot net
http://www.blackberryempire.com/forum/buysell/single_ad.php?ad_id=6
http://posterous-spaces.posterous.com/
http://googleclone.tumblr.com/
http://googleclone.tumblr.com/
https://profiled.com/mobile/blog
[2012-04-06 23:49:55] phpbugs at deep-freeze dot ca
Description:
Casting from an object to an array with numeric key leaves the element
inaccessible.
Given a object with a field whose name is numeric, after a cast to array, there
is no means to access the element.
That is $array['804496778'] yields an undefined error
array_key_exists(804496778, $array); yields false
array_key_exists('804496778', $array); fields false
yet a var_dump($array); shows this element;
and a array_keys($array); returns array(1) { [0] string(9) "804496778" }
Test script:
---
$object = new stdClass();
$key = '804496778';
$object->{$key} = "Hello;
$array = (array)$object;
echo $array[$key], ' ', (int)array_key_exists($key, $array), PHP_EOL;
var_dump($array)
Expected result:
Hello 1
array(1) {
["804496778"]=>
string(5) "Hello"
}
Actual result:
--
PHP Notice: Undefined index: 804496778 in /home/icewolf/bug.php on line 6
0
array(1) {
["804496778"]=>
string(5) "Hello"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=61655&edit=1
Bug #55334 [Com]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Comment by: ricardo dot nuno dot rodrigues at hotmail dot com Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Assigned Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Assigned To:johannes Block user comment: N Private report: N New Comment: Hi there, In PHP 5.4 TS VC9 (Win) I have the same problem. Under stress goes down. With file mysql_test.php: Under: ab -n 1 -c 50 http://127.0.0.1/mysql_test.php It restart server (apache 2.2.21). Sometimes creates a delay. Under xdebug there's a big time to connect. Thanks Ricardo Previous Comments: [2012-03-12 17:21:41] paj...@php.net Johannes, See last comment, I can also still reproduce it locally (dual quad). [2012-03-09 23:08:26] mattfic...@php.net To repro this problem, your test environment needs to have 4+ cpus, which the environment I was previously using didn't have. [2012-03-09 19:07:38] mattfic...@php.net Closing bug [2012-03-09 19:03:14] mattfic...@php.net Using 5_3 r324027, with Apache 2.2 on Windows 2008r2sp0, I can no longer reproduce this bug. I think this bug is fixed. [2012-03-09 09:52:00] johan...@php.net For 5.3 please use svn snaps. Can you share more details on the test you're doing and the effects you see? 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=55334 -- Edit this bug report at https://bugs.php.net/bug.php?id=55334&edit=1
Bug #51800 [Com]: proc_open on Windows hangs forever
Edit report at https://bugs.php.net/bug.php?id=51800&edit=1
ID: 51800
Comment by: s...@php.net
Reported by:ph dot wolfer at googlemail dot com
Summary:proc_open on Windows hangs forever
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows
PHP Version:5.2.13
Block user comment: N
Private report: N
New Comment:
I could reproduce this on PHP 5.4.0 as soon as $data is longer than 4096 bytes.
With $data = str_repeat("a", 4097); in process.php it hangs forever, while with
any number until 4096 it passes.
Previous Comments:
[2012-02-19 14:37:42] nicolas dot sauveur at gmail dot com
This seems similar as https://bugs.php.net/bug.php?id=60120 .
Only partially fixed for me ( thus not fixed ) in php 5.3.9.
[2010-05-12 17:31:30] ph dot wolfer at googlemail dot com
Description:
On Windows, if you use proc_open to open another process and if you use a pipe
for STDERR, the script will hang when trying to read from STDOUT or STDERR if
the opened process outputs a lot of data.
See the example below. The called script process.php is a simple script which
writes some data to STDOUT and STDERR:
$data = str_repeat("a", 1);
fwrite(STDOUT, $data);
fwrite(STDERR, $data);
exit(0);
If called as shown below, the script will hang in the loop that reads the
STDOUT pipe. The same would happen if you would read the STDERR pipe before. If
you lower the amount of data in process.php the script will run to the end. In
my tests everything below ~2000 bytes was ok, above this value the script hang.
If you change the script below to not include the STDERR descriptor or if you
change the STDERR descriptor to a file output everything will work fine. Also
if you close the STDERR pipe before reading from STDOUT it will work. There
seems to be some deadlock.
The same script works fine on Linux.
This was tested with Windows Server 2008, IIS, PHP 5.2.13. But I have seen this
on other Windows configurations as well.
Test script:
---
array("pipe", "r"),// stdin
1 => array("pipe", "w"),// stdout
2 => array("pipe", "w") // stderr
);
$process = proc_open($cmd, $descriptors, $pipes);
if (is_resource($process))
{
fclose($pipes[0]);
while (!feof($pipes[1]))
$stdout .= fread($pipes[1], 1024);
fclose($pipes[1]);
while (!feof($pipes[2]))
$stderr .= fread($pipes[2], 1024);
fclose($pipes[2]);
$status = proc_close($process);
}
print_r(array(
"status" => $status,
"stdout" => $stdout,
"stderr" => $stderr,
));
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=51800&edit=1
Bug #61660 [Opn->Csd]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Updated by: ni...@php.net Reported by:krtek4+php at gmail dot com Summary:bin2hex(hex2bin($data)) != $data -Status: Open +Status: Closed Type: Bug Package:*General Issues Operating System: Debian Linux PHP Version:5.4.1RC1 -Assigned To: +Assigned To:nikic Block user comment: N Private report: N New Comment: After some further discussion on IRC we agreed that it is best to throw a warning. The reasoning is as outlined in my previous comment. The warning is implemented with https://github.com/php/php-src/commit/7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0. Previous Comments: [2012-04-08 20:45:41] ni...@php.net Automatic comment on behalf of nikic Revision: http://git.php.net/?p=php-src.git;a=commit;h=7ae93a2c4c8a51cc2aec9977ce3c83c100e382a0 Log: Fix bug #61660: bin2hex(hex2bin($data)) != $data [2012-04-08 16:23:50] theanomaly dot is at gmail dot com We have no problem type juggling a string to an int as the first non-whitespace, non-zero number character... var_dump(1 + "\t\r\n 0001"); // int(2) Then, equally, we should have no problem interpreting a hexadecimal representation of 1 as 01. :) [2012-04-08 16:05:02] ras...@php.net > The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Why would af52b ever mean af52b0 ? That's like saying 15 could be interpreted as 150 sometimes. [2012-04-08 15:25:52] ni...@php.net In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should throw a warning. The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Both are valid interpretations, depending on the use case. Because of this I think a warning is more appropriate. It signals the user that the data is wrong. He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in his particular situation. Blindly adding the padding on the other hand will probably be quite unexpected. Especially when adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it only changes one byte). [2012-04-08 13:20:35] krtek4+php at gmail dot com You are right, there was a bug in the patch I sent. I updated it on github. Thanks for the comment ! 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=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Comment by: theanomaly dot is at gmail dot com Reported by:krtek4+php at gmail dot com Summary:bin2hex(hex2bin($data)) != $data Status: Open Type: Bug Package:*General Issues Operating System: Debian Linux PHP Version:5.4.1RC1 Block user comment: N Private report: N New Comment: We have no problem type juggling a string to an int as the first non-whitespace, non-zero number character... var_dump(1 + "\t\r\n 0001"); // int(2) Then, equally, we should have no problem interpreting a hexadecimal representation of 1 as 01. :) Previous Comments: [2012-04-08 16:05:02] ras...@php.net > The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Why would af52b ever mean af52b0 ? That's like saying 15 could be interpreted as 150 sometimes. [2012-04-08 15:25:52] ni...@php.net In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should throw a warning. The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Both are valid interpretations, depending on the use case. Because of this I think a warning is more appropriate. It signals the user that the data is wrong. He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in his particular situation. Blindly adding the padding on the other hand will probably be quite unexpected. Especially when adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it only changes one byte). [2012-04-08 13:20:35] krtek4+php at gmail dot com You are right, there was a bug in the patch I sent. I updated it on github. Thanks for the comment ! [2012-04-08 12:23:32] theanomaly dot is at gmail dot com @krtek4+php I didn't mean to step on any toes, honestly. I think your patch probably looks way cleaner than mine, but when I tried compiling your patch it did not work for me. The test didn't pass. var_dump(bin2hex(hex2bin(1))); // returned string(0) "" Maybe I didn't do it right, but that's the only reason I submitted another patch after I tested again on the PHP-5.4 branch. [2012-04-08 10:08:14] krtek4+php at gmail dot com If I could intervene, my patch does exactly the same thing without adding a new test for each iteration of the loop. Mine has only one modulo (%) outside of the loop and the new test is executed only once at the first pass assuming the string is a correct hexadecimal value. Like said in your last comment, the % operation can even be optimized with a '& 1' if needed. 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=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61660 [Opn]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Updated by: ras...@php.net Reported by:krtek4+php at gmail dot com Summary:bin2hex(hex2bin($data)) != $data Status: Open Type: Bug Package:*General Issues Operating System: Debian Linux PHP Version:5.4.1RC1 Block user comment: N Private report: N New Comment: > The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Why would af52b ever mean af52b0 ? That's like saying 15 could be interpreted as 150 sometimes. Previous Comments: [2012-04-08 15:25:52] ni...@php.net In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should throw a warning. The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Both are valid interpretations, depending on the use case. Because of this I think a warning is more appropriate. It signals the user that the data is wrong. He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in his particular situation. Blindly adding the padding on the other hand will probably be quite unexpected. Especially when adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it only changes one byte). [2012-04-08 13:20:35] krtek4+php at gmail dot com You are right, there was a bug in the patch I sent. I updated it on github. Thanks for the comment ! [2012-04-08 12:23:32] theanomaly dot is at gmail dot com @krtek4+php I didn't mean to step on any toes, honestly. I think your patch probably looks way cleaner than mine, but when I tried compiling your patch it did not work for me. The test didn't pass. var_dump(bin2hex(hex2bin(1))); // returned string(0) "" Maybe I didn't do it right, but that's the only reason I submitted another patch after I tested again on the PHP-5.4 branch. [2012-04-08 10:08:14] krtek4+php at gmail dot com If I could intervene, my patch does exactly the same thing without adding a new test for each iteration of the loop. Mine has only one modulo (%) outside of the loop and the new test is executed only once at the first pass assuming the string is a correct hexadecimal value. Like said in your last comment, the % operation can even be optimized with a '& 1' if needed. [2012-04-08 10:01:22] larue...@php.net @theanomaly as we talked, since Rasmus said it's okey, then I have no objection. 2 suggestions : 1. use oddlen & 1 instead of oddlen % 2 2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold it and it's better for you to make a pull request by yourself, let me know if you need help on that :) 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=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1 ID: 61660 Comment by: ni...@php.net Reported by:krtek4+php at gmail dot com Summary:bin2hex(hex2bin($data)) != $data Status: Open Type: Bug Package:*General Issues Operating System: Debian Linux PHP Version:5.4.1RC1 Block user comment: N Private report: N New Comment: In my eyes hex2bin should not try to fix the corrupt data by padding it with zero. Instead it should throw a warning. The reason is simple: A padding can be either added on the left or on the right. E.g. "af52b" could be interpreted both as "0af52b" and as "af52b0". Both are valid interpretations, depending on the use case. Because of this I think a warning is more appropriate. It signals the user that the data is wrong. He can always easily fix it by adding a zero to either of the sides, whatever is more appropriate in his particular situation. Blindly adding the padding on the other hand will probably be quite unexpected. Especially when adding the 0 on the left side all the data will be shifted by 4 bits. This means that the whole data will be corrupted. All bytes will change. (Adding a padding on the right is less intrusive as it only changes one byte). Previous Comments: [2012-04-08 13:20:35] krtek4+php at gmail dot com You are right, there was a bug in the patch I sent. I updated it on github. Thanks for the comment ! [2012-04-08 12:23:32] theanomaly dot is at gmail dot com @krtek4+php I didn't mean to step on any toes, honestly. I think your patch probably looks way cleaner than mine, but when I tried compiling your patch it did not work for me. The test didn't pass. var_dump(bin2hex(hex2bin(1))); // returned string(0) "" Maybe I didn't do it right, but that's the only reason I submitted another patch after I tested again on the PHP-5.4 branch. [2012-04-08 10:08:14] krtek4+php at gmail dot com If I could intervene, my patch does exactly the same thing without adding a new test for each iteration of the loop. Mine has only one modulo (%) outside of the loop and the new test is executed only once at the first pass assuming the string is a correct hexadecimal value. Like said in your last comment, the % operation can even be optimized with a '& 1' if needed. [2012-04-08 10:01:22] larue...@php.net @theanomaly as we talked, since Rasmus said it's okey, then I have no objection. 2 suggestions : 1. use oddlen & 1 instead of oddlen % 2 2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold it and it's better for you to make a pull request by yourself, let me know if you need help on that :) [2012-04-08 10:00:43] krtek4+php at gmail dot com The internal representation must always be aligned on 8 bits, thus we have no choice to pad with 0 bits at the beginning, 1000 and 1000 is the exact same value in binary and I think the actual patch is correct. The new problem is that the reverse operation, i.e. bin2hex, should remove the added 0 bit at the beginning. @theanomaly ; decbin works just fine since it returns a string composed of 0s and 1s and not a "binary value". hex2bin / bin2hex are the only function I'm aware of working this way. BTW, why did you sent another patch ? mine is doing exactly the same as yours and is working fine. 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=61660 -- Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61668 [Com]: ext\standard\tests\file\rename_variation13-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61668&edit=1 ID: 61668 Comment by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation13-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: php 5.4 has additionally the line numbers shifted in the test, apply as well with git apply --binary 61668_php5.4.diff git thinks it's binary because of the \0 byte, previously it wasn't echoed and was not in the output check, but now it must be there Previous Comments: [2012-04-08 13:25:30] a...@php.net The following patch has been added/updated: Patch Name: 61668_php5.4.diff Revision: 1333891530 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.4.diff&revision=1333891530 [2012-04-08 12:26:55] a...@php.net 61668_php5.3.diff should be applied with git apply --binary 61668_php5.3.diff [2012-04-08 12:26:16] a...@php.net The following patch has been added/updated: Patch Name: 61668_php5.3.diff Revision: 1333887976 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.3.diff&revision=1333887976 [2012-04-08 11:29:51] a...@php.net Description: Test diff on php 5.3: 040+ -- 6 testing '^@' string -- 040- -- 6 testing ' Test diff on php 5.4: 005+ Warning: rename(-1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 005- Warning: rename(-1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 010+ Warning: rename(1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 010- Warning: rename(1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 042+ Warning: rename() expects parameter 2 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 042- Warning: rename() expects parameter 2 to be a valid path, string given in %srename_variation13-win32.php on line 42 045+ Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 045- Warning: file_exists() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 43 047+ Warning: rename() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 047- Warning: rename() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 50 051+ Warning: rename() expects parameter 2 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 051- Warning: rename() expects parameter 2 to be a valid path, array given in %srename_variation13-win32.php on line 42 054+ Warning: file_exists() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 054- Warning: file_exists() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 43 056+ Warning: rename() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 056- Warning: rename() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 50 060+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 060- Warning: rename(%safile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 063+ Warning: rename(/no/such/file/dir,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot fin
Bug #61668 [PATCH]: ext\standard\tests\file\rename_variation13-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61668&edit=1 ID: 61668 Patch added by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation13-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 61668_php5.4.diff Revision: 1333891530 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.4.diff&revision=1333891530 Previous Comments: [2012-04-08 12:26:55] a...@php.net 61668_php5.3.diff should be applied with git apply --binary 61668_php5.3.diff [2012-04-08 12:26:16] a...@php.net The following patch has been added/updated: Patch Name: 61668_php5.3.diff Revision: 1333887976 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.3.diff&revision=1333887976 [2012-04-08 11:29:51] a...@php.net Description: Test diff on php 5.3: 040+ -- 6 testing '^@' string -- 040- -- 6 testing ' Test diff on php 5.4: 005+ Warning: rename(-1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 005- Warning: rename(-1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 010+ Warning: rename(1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 010- Warning: rename(1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 042+ Warning: rename() expects parameter 2 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 042- Warning: rename() expects parameter 2 to be a valid path, string given in %srename_variation13-win32.php on line 42 045+ Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 045- Warning: file_exists() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 43 047+ Warning: rename() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 047- Warning: rename() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 50 051+ Warning: rename() expects parameter 2 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 051- Warning: rename() expects parameter 2 to be a valid path, array given in %srename_variation13-win32.php on line 42 054+ Warning: file_exists() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 054- Warning: file_exists() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 43 056+ Warning: rename() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 056- Warning: rename() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 50 060+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 060- Warning: rename(%safile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 063+ Warning: rename(/no/such/file/dir,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 063- Warning: rename(/no/such/file/dir,%safile.tmp): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 50 067+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/re
Bug #61660 [Opn]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
User updated by:krtek4+php at gmail dot com
Reported by:krtek4+php at gmail dot com
Summary:bin2hex(hex2bin($data)) != $data
Status: Open
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.4.1RC1
Block user comment: N
Private report: N
New Comment:
You are right, there was a bug in the patch I sent. I updated it on github.
Thanks for the comment !
Previous Comments:
[2012-04-08 12:23:32] theanomaly dot is at gmail dot com
@krtek4+php
I didn't mean to step on any toes, honestly. I think your patch probably looks
way cleaner than mine, but when I tried compiling your patch it did not work
for
me. The test didn't pass.
var_dump(bin2hex(hex2bin(1))); // returned string(0) ""
Maybe I didn't do it right, but that's the only reason I submitted another
patch
after I tested again on the PHP-5.4 branch.
[2012-04-08 10:08:14] krtek4+php at gmail dot com
If I could intervene, my patch does exactly the same thing without adding a new
test for each iteration of the loop.
Mine has only one modulo (%) outside of the loop and the new test is executed
only
once at the first pass assuming the string is a correct hexadecimal value.
Like said in your last comment, the % operation can even be optimized with a '&
1'
if needed.
[2012-04-08 10:01:22] larue...@php.net
@theanomaly as we talked, since Rasmus said it's okey, then I have no objection.
2 suggestions :
1. use oddlen & 1 instead of oddlen % 2
2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold
it
and it's better for you to make a pull request by yourself, let me know if you
need help on that :)
[2012-04-08 10:00:43] krtek4+php at gmail dot com
The internal representation must always be aligned on 8 bits, thus we have no
choice to pad with 0 bits at the beginning, 1000 and 1000 is the exact same
value in binary and I think the actual patch is correct.
The new problem is that the reverse operation, i.e. bin2hex, should remove the
added 0 bit at the beginning.
@theanomaly ; decbin works just fine since it returns a string composed of 0s
and 1s and not a "binary value". hex2bin / bin2hex are the only function I'm
aware of working this way.
BTW, why did you sent another patch ? mine is doing exactly the same as yours
and is working fine.
[2012-04-08 09:42:25] theanomaly dot is at gmail dot com
@laruence
I've replaced the last patch with a better patch because I realized I created a
memory leak and that was a poor strategy.
I can't understand why there should be any confusion about whether it's an
octal
value or a hexadecimal value though. Since when should using bin2hex() ever
leave us with the expectation that would _ever_ get back an octal value?
I might be missing something here, but hex2bin() should always be expecting a
hexadecimal value and bin2hex() should always leave us with the expectation of
a
hexadecimal value. I see nothing wrong with padding the value to an even number
otherwise the result is hex2bin() isn't doing what it's supposed to be doing.
It
makes sense to me that even if the client sends a value of '1' that it's
completely expected behavior that '01' and '1' should both be a valid
hexadecimal value.
To me it just makes no sense to punish the client for forgetting to pad the
value by returning false data. At the very least we should be issuing a warning
to let the client know they have sent unexpected data and then this can be
documented behavior. But why waste time fixing it to issue E_WARNINGs when this
patch fixes the issue completely? Besides hex2bin is returning a string. It's
not like the user can inadvertently use it as an octal value.
var_dump('0123' + '0123'); // int(246)
This would be silly not to fix in my opinion. Especially since it's such an
easy
fix. At least run the patch and let me know which test case you can come up
with
that would break any of PHP's already existing documented behavior by making
this modification?
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=61660
--
Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61668 [Com]: ext\standard\tests\file\rename_variation13-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61668&edit=1 ID: 61668 Comment by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation13-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: 61668_php5.3.diff should be applied with git apply --binary 61668_php5.3.diff Previous Comments: [2012-04-08 12:26:16] a...@php.net The following patch has been added/updated: Patch Name: 61668_php5.3.diff Revision: 1333887976 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.3.diff&revision=1333887976 [2012-04-08 11:29:51] a...@php.net Description: Test diff on php 5.3: 040+ -- 6 testing '^@' string -- 040- -- 6 testing ' Test diff on php 5.4: 005+ Warning: rename(-1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 005- Warning: rename(-1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 010+ Warning: rename(1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 010- Warning: rename(1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 042+ Warning: rename() expects parameter 2 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 042- Warning: rename() expects parameter 2 to be a valid path, string given in %srename_variation13-win32.php on line 42 045+ Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 045- Warning: file_exists() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 43 047+ Warning: rename() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 047- Warning: rename() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 50 051+ Warning: rename() expects parameter 2 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 051- Warning: rename() expects parameter 2 to be a valid path, array given in %srename_variation13-win32.php on line 42 054+ Warning: file_exists() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 054- Warning: file_exists() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 43 056+ Warning: rename() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 056- Warning: rename() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 50 060+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 060- Warning: rename(%safile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 063+ Warning: rename(/no/such/file/dir,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 063- Warning: rename(/no/such/file/dir,%safile.tmp): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 50 067+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,php/php): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 067- Warning: rename(%safile.tmp,php/php): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.p
Bug #61668 [PATCH]: ext\standard\tests\file\rename_variation13-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61668&edit=1 ID: 61668 Patch added by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation13-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: windows PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 61668_php5.3.diff Revision: 1333887976 URL: https://bugs.php.net/patch-display.php?bug=61668&patch=61668_php5.3.diff&revision=1333887976 Previous Comments: [2012-04-08 11:29:51] a...@php.net Description: Test diff on php 5.3: 040+ -- 6 testing '^@' string -- 040- -- 6 testing ' Test diff on php 5.4: 005+ Warning: rename(-1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 005- Warning: rename(-1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 010+ Warning: rename(1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 010- Warning: rename(1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 042+ Warning: rename() expects parameter 2 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 042- Warning: rename() expects parameter 2 to be a valid path, string given in %srename_variation13-win32.php on line 42 045+ Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 045- Warning: file_exists() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 43 047+ Warning: rename() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 047- Warning: rename() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 50 051+ Warning: rename() expects parameter 2 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 051- Warning: rename() expects parameter 2 to be a valid path, array given in %srename_variation13-win32.php on line 42 054+ Warning: file_exists() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 054- Warning: file_exists() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 43 056+ Warning: rename() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 056- Warning: rename() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 50 060+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 060- Warning: rename(%safile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 063+ Warning: rename(/no/such/file/dir,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 063- Warning: rename(/no/such/file/dir,%safile.tmp): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 50 067+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,php/php): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 067- Warning: rename(%safile.tmp,php/php): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 070+ Warning: rename(php/php,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
Comment by: theanomaly dot is at gmail dot com
Reported by:krtek4+php at gmail dot com
Summary:bin2hex(hex2bin($data)) != $data
Status: Open
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.4.1RC1
Block user comment: N
Private report: N
New Comment:
@krtek4+php
I didn't mean to step on any toes, honestly. I think your patch probably looks
way cleaner than mine, but when I tried compiling your patch it did not work
for
me. The test didn't pass.
var_dump(bin2hex(hex2bin(1))); // returned string(0) ""
Maybe I didn't do it right, but that's the only reason I submitted another
patch
after I tested again on the PHP-5.4 branch.
Previous Comments:
[2012-04-08 10:08:14] krtek4+php at gmail dot com
If I could intervene, my patch does exactly the same thing without adding a new
test for each iteration of the loop.
Mine has only one modulo (%) outside of the loop and the new test is executed
only
once at the first pass assuming the string is a correct hexadecimal value.
Like said in your last comment, the % operation can even be optimized with a '&
1'
if needed.
[2012-04-08 10:01:22] larue...@php.net
@theanomaly as we talked, since Rasmus said it's okey, then I have no objection.
2 suggestions :
1. use oddlen & 1 instead of oddlen % 2
2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold
it
and it's better for you to make a pull request by yourself, let me know if you
need help on that :)
[2012-04-08 10:00:43] krtek4+php at gmail dot com
The internal representation must always be aligned on 8 bits, thus we have no
choice to pad with 0 bits at the beginning, 1000 and 1000 is the exact same
value in binary and I think the actual patch is correct.
The new problem is that the reverse operation, i.e. bin2hex, should remove the
added 0 bit at the beginning.
@theanomaly ; decbin works just fine since it returns a string composed of 0s
and 1s and not a "binary value". hex2bin / bin2hex are the only function I'm
aware of working this way.
BTW, why did you sent another patch ? mine is doing exactly the same as yours
and is working fine.
[2012-04-08 09:42:25] theanomaly dot is at gmail dot com
@laruence
I've replaced the last patch with a better patch because I realized I created a
memory leak and that was a poor strategy.
I can't understand why there should be any confusion about whether it's an
octal
value or a hexadecimal value though. Since when should using bin2hex() ever
leave us with the expectation that would _ever_ get back an octal value?
I might be missing something here, but hex2bin() should always be expecting a
hexadecimal value and bin2hex() should always leave us with the expectation of
a
hexadecimal value. I see nothing wrong with padding the value to an even number
otherwise the result is hex2bin() isn't doing what it's supposed to be doing.
It
makes sense to me that even if the client sends a value of '1' that it's
completely expected behavior that '01' and '1' should both be a valid
hexadecimal value.
To me it just makes no sense to punish the client for forgetting to pad the
value by returning false data. At the very least we should be issuing a warning
to let the client know they have sent unexpected data and then this can be
documented behavior. But why waste time fixing it to issue E_WARNINGs when this
patch fixes the issue completely? Besides hex2bin is returning a string. It's
not like the user can inadvertently use it as an octal value.
var_dump('0123' + '0123'); // int(246)
This would be silly not to fix in my opinion. Especially since it's such an
easy
fix. At least run the patch and let me know which test case you can come up
with
that would break any of PHP's already existing documented behavior by making
this modification?
[2012-04-08 08:07:32] larue...@php.net
@theanomaly I have tried the similar way as you did. but the key problem is
the
result will be considered as a oct number.
reads:
"123" != "0123"
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=61660
--
Edit this bug report at https://bugs.php.net/bug.php?id=61660&edit=1
Bug #61671 [Com]: ext\spl\tests\fileobject_003.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61671&edit=1
ID: 61671
Comment by: a...@php.net
Reported by:a...@php.net
Summary:ext\spl\tests\fileobject_003.phpt fails
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
On windows SplFileObject doesn't work as expected with directories,
because the functionality of php_stream_open_wrapper_ex can't open
dir streams on windows. Fixing this may have long range consequences
but would be rather correct instead of just fixing the test behaviour.
Previous Comments:
[2012-04-08 11:48:10] a...@php.net
Description:
Test diff:
043+
044+ Fatal error: Uncaught exception 'RuntimeException' with message
'SplFileObject::__construct(C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests/):
failed to open stream: No such file or directory' in
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php:18
045+ Stack trace:
046+ #0 C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php(18):
SplFileObject->__construct('C:\php-sdk\php5...')
047+ #1 C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php(35):
test('C:\php-sdk\php5...', 's', 'l')
048+ #2 {main}
049+ thrown in
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php on line 18
043- %s(%d) "%stests/"
044- string(%d) "%stests"
045- bool(true)
046- string(5) "tests"
047- bool(true)
048- string(%d) "%sspl"
049- bool(true)
050- string(%d) "%stests"
051- string(%d) "tests"
052- string(%d) "%sspl"
053- ===2===
054- object(SplFileInfo)#%d (2) {
055- ["pathName":"SplFileInfo":private]=>
056- string(%d) "%s"
057- ["fileName":"SplFileInfo":private]=>
058- string(%d) "%s"
059- }
060- object(SplFileInfo)#%d (2) {
061- ["pathName":"SplFileInfo":private]=>
062- string(%d) "%s"
063- ["fileName":"SplFileInfo":private]=>
064- string(%d) "%s"
065- }
066- bool(false)
067- bool(true)
068- bool(true)
069- %s(%d) "%stests"
070- string(%d) "%stests"
071- bool(true)
072- string(%d) "tests"
073- bool(true)
074- string(%d) "%sspl"
075- bool(true)
076- string(%d) "%stests"
077- string(5) "tests"
078- string(%d) "%sspl"
079- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit this bug report at https://bugs.php.net/bug.php?id=61671&edit=1
[PHP-BUG] Bug #61671 [NEW]: ext\spl\tests\fileobject_003.phpt fails
From: ab
Operating system: Windows
PHP version: 5.3.10
Package: SPL related
Bug Type: Bug
Bug description:ext\spl\tests\fileobject_003.phpt fails
Description:
Test diff:
043+
044+ Fatal error: Uncaught exception 'RuntimeException' with message
'SplFileObject::__construct(C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests/):
failed to open stream: No such file or directory' in
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php:18
045+ Stack trace:
046+ #0
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php(18):
SplFileObject->__construct('C:\php-sdk\php5...')
047+ #1
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php(35):
test('C:\php-sdk\php5...', 's', 'l')
048+ #2 {main}
049+ thrown in
C:\php-sdk\php53\vc9\x86\php-src\ext\spl\tests\fileobject_003.php on line
18
043- %s(%d) "%stests/"
044- string(%d) "%stests"
045- bool(true)
046- string(5) "tests"
047- bool(true)
048- string(%d) "%sspl"
049- bool(true)
050- string(%d) "%stests"
051- string(%d) "tests"
052- string(%d) "%sspl"
053- ===2===
054- object(SplFileInfo)#%d (2) {
055- ["pathName":"SplFileInfo":private]=>
056- string(%d) "%s"
057- ["fileName":"SplFileInfo":private]=>
058- string(%d) "%s"
059- }
060- object(SplFileInfo)#%d (2) {
061- ["pathName":"SplFileInfo":private]=>
062- string(%d) "%s"
063- ["fileName":"SplFileInfo":private]=>
064- string(%d) "%s"
065- }
066- bool(false)
067- bool(true)
068- bool(true)
069- %s(%d) "%stests"
070- string(%d) "%stests"
071- bool(true)
072- string(%d) "tests"
073- bool(true)
074- string(%d) "%sspl"
075- bool(true)
076- string(%d) "%stests"
077- string(5) "tests"
078- string(%d) "%sspl"
079- ===DONE===
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61671&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61671&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61671&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61671&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61671&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61671&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61671&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61671&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61671&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61671&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61671&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61671&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61671&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61671&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61671&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61671&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61671&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61671&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61671&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61671&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61671&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61671&r=mysqlcfg
Bug #61669 [PATCH]: ext\standard\tests\file\rename_variation7-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61669&edit=1 ID: 61669 Patch added by: a...@php.net Reported by:a...@php.net Summary:ext\standard\tests\file\rename_variation7-win32.phpt fails Status: Open Type: Bug Package:*Directory/Filesystem functions Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 61669.diff Revision: 1333885396 URL: https://bugs.php.net/patch-display.php?bug=61669&patch=61669.diff&revision=1333885396 Previous Comments: [2012-04-08 11:36:58] a...@php.net Description: Test diff: 003+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 12 003- Warning: readlink(): Could not open file (error 2) in %s on line %d 006+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link2), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 13 006- Warning: readlink(): Could not open file (error 2) in %s on line %d fail is php 5.3 only Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61669&edit=1
[PHP-BUG] Bug #61669 [NEW]: ext\standard\tests\file\rename_variation7-win32.phpt fails
From: ab Operating system: Windows PHP version: 5.3.10 Package: *Directory/Filesystem functions Bug Type: Bug Bug description:ext\standard\tests\file\rename_variation7-win32.phpt fails Description: Test diff: 003+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 12 003- Warning: readlink(): Could not open file (error 2) in %s on line %d 006+ Warning: readlink(): readlink failed to read the symbolic link (C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php.tmp.link2), error 2) in C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file\rename_variation7-win32.php on line 13 006- Warning: readlink(): Could not open file (error 2) in %s on line %d fail is php 5.3 only Expected result: test pass Actual result: -- test fail -- Edit bug report at https://bugs.php.net/bug.php?id=61669&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61669&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61669&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61669&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61669&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61669&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61669&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61669&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61669&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61669&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61669&r=support Expected behavior: https://bugs.php.net/fix.php?id=61669&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61669&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61669&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61669&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61669&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61669&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61669&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61669&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61669&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61669&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61669&r=mysqlcfg
[PHP-BUG] Bug #61668 [NEW]: ext\standard\tests\file\rename_variation13-win32.phpt fails
From: ab Operating system: windows PHP version: Irrelevant Package: *Directory/Filesystem functions Bug Type: Bug Bug description:ext\standard\tests\file\rename_variation13-win32.phpt fails Description: Test diff on php 5.3: 040+ -- 6 testing '^@' string -- 040- -- 6 testing ' Test diff on php 5.4: 005+ Warning: rename(-1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 005- Warning: rename(-1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 010+ Warning: rename(1,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the file specified. (code: 2) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 010- Warning: rename(1,%safile.tmp): The system cannot find the file specified. (code: 2) in %srename_variation13-win32.php on line 50 042+ Warning: rename() expects parameter 2 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 042- Warning: rename() expects parameter 2 to be a valid path, string given in %srename_variation13-win32.php on line 42 045+ Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 045- Warning: file_exists() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 43 047+ Warning: rename() expects parameter 1 to be a valid path, string given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 047- Warning: rename() expects parameter 1 to be a valid path, string given in %srename_variation13-win32.php on line 50 051+ Warning: rename() expects parameter 2 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 051- Warning: rename() expects parameter 2 to be a valid path, array given in %srename_variation13-win32.php on line 42 054+ Warning: file_exists() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 46 054- Warning: file_exists() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 43 056+ Warning: rename() expects parameter 1 to be a valid path, array given in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 056- Warning: rename() expects parameter 1 to be a valid path, array given in %srename_variation13-win32.php on line 50 060+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 060- Warning: rename(%safile.tmp,/no/such/file/dir): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 063+ Warning: rename(/no/such/file/dir,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 063- Warning: rename(/no/such/file/dir,%safile.tmp): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 50 067+ Warning: rename(C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp,php/php): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 45 067- Warning: rename(%safile.tmp,php/php): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 42 070+ Warning: rename(php/php,C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file/renameVar13/afile.tmp): The system cannot find the path specified. (code: 3) in C:\php-sdk\php54\vc9\x86\php-src\ext\standard\tests\file\rename_variation13-win32.php on line 53 070- Warning: rename(php/php,%safile.tmp): The system cannot find the path specified. (code: 3) in %srename_variation13-win32.php on line 50 Expected result: test pass Actual result: -- test fail -- Edit bug report at https://bugs.php.net/bug.php?id=61668&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61668&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61668&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?
Bug #61667 [Com]: ext\standard\tests\file\glob_variation-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61667&edit=1
ID: 61667
Comment by: a...@php.net
Reported by:a...@php.net
Summary:ext\standard\tests\file\glob_variation-win32.phpt
fails
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: windows
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
the test passes on php >=5.4, only the php 5.3 has changed
Previous Comments:
[2012-04-08 11:14:11] a...@php.net
The following patch has been added/updated:
Patch Name: 61667.diff
Revision: 1333883651
URL:
https://bugs.php.net/patch-display.php?bug=61667&patch=61667.diff&revision=1333883651
[2012-04-08 11:12:53] a...@php.net
Description:
Test diff:
240+ bool(false)
241+ bool(false)
242+ bool(false)
243+ bool(false)
244+ bool(false)
245+ bool(false)
246+
247+ -- Iteration 9 --
248- string(%d) "%s/glob_variation/WONDER5"
255- -- Iteration 9 --
256+ string(33) "$file_path/glob_variation/wonder5"
263+ -- Iteration 10 --
264- string(%d) "$file_path/glob_variation/wonder5"
271- -- Iteration 10 --
272+ string(80)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/?wonder?"
279+ -- Iteration 11 --
280- string(%d) "%s/glob_variation/?wonder?"
287- -- Iteration 11 --
288+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder?"
295+ -- Iteration 12 --
296- string(%d) "%s/glob_variation/wonder?"
303- -- Iteration 12 --
304- array(0) {
304+ string(1) "1"
306- array(0) {
308- array(0) {
311+ *** Testing glob() with pattern within braces ***
312+ array(1) {
313+ [0]=>
314+ string(83)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder12345"
312- string(%d) "1"
316+
317+ *** Testing glob() on directories ***
318+ -- Iteration 1 --
319+ array(1) {
320+ [0]=>
321+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
318-
319- *** Testing glob() with pattern within braces ***
322- string(%d) "%s/glob_variation/wonder12345"
323+ -- Iteration 2 --
324+ array(1) {
325+ [0]=>
326+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
324-
325- *** Testing glob() on directories ***
326- -- Iteration 1 --
328+ -- Iteration 3 --
331+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
331- -- Iteration 2 --
332- array(1) {
333- [0]=>
334- string(%d) "%s/glob_variation/wonder1"
333+ -- Iteration 4 --
336+ -- Iteration 5 --
336- -- Iteration 3 --
339+ -- Iteration 6 --
342+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
343+ }
344+ -- Iteration 7 --
345+ array(0) {
346+ }
347+ -- Iteration 8 --
348+ bool(false)
349+ -- Iteration 9 --
350+ array(0) {
351+ }
352+ -- Iteration 10 --
353+ array(0) {
355+ -- Iteration 11 --
360+ -- Iteration 12 --
361+ array(0) {
363+ Done
337- array(1) {
338- [0]=>
339- string(%d) "%s/glob_variation/wonder1"
340- }
341- -- Iteration 4 --
342- array(0) {
343- }
344- -- Iteration 5 --
345- array(0) {
346- }
347- -- Iteration 6 --
348- array(1) {
349- [0]=>
350- string(%d) "%s/glob_variation/wonder1"
351- }
352- -- Iteration 7 --
353- array(0) {
354- }
355- -- Iteration 8 --
356- array(0) {
357- }
358- -- Iteration 9 --
359- array(0) {
360- }
361- -- Iteration 10 --
362- array(0) {
363- }
364- -- Iteration 11 --
365- array(1) {
366- [0]=>
367- string(%d) "%s/glob_variation/wonder1"
368- }
369- -- Iteration 12 --
370- array(0) {
371- }
372- Done
Expected result:
test pass
Actual result:
--
test fail
--
Edit this bug report at https://bugs.php.net/bug.php?id=61667&edit=1
Bug #61667 [PATCH]: ext\standard\tests\file\glob_variation-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61667&edit=1
ID: 61667
Patch added by: a...@php.net
Reported by:a...@php.net
Summary:ext\standard\tests\file\glob_variation-win32.phpt
fails
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: windows
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 61667.diff
Revision: 1333883651
URL:
https://bugs.php.net/patch-display.php?bug=61667&patch=61667.diff&revision=1333883651
Previous Comments:
[2012-04-08 11:12:53] a...@php.net
Description:
Test diff:
240+ bool(false)
241+ bool(false)
242+ bool(false)
243+ bool(false)
244+ bool(false)
245+ bool(false)
246+
247+ -- Iteration 9 --
248- string(%d) "%s/glob_variation/WONDER5"
255- -- Iteration 9 --
256+ string(33) "$file_path/glob_variation/wonder5"
263+ -- Iteration 10 --
264- string(%d) "$file_path/glob_variation/wonder5"
271- -- Iteration 10 --
272+ string(80)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/?wonder?"
279+ -- Iteration 11 --
280- string(%d) "%s/glob_variation/?wonder?"
287- -- Iteration 11 --
288+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder?"
295+ -- Iteration 12 --
296- string(%d) "%s/glob_variation/wonder?"
303- -- Iteration 12 --
304- array(0) {
304+ string(1) "1"
306- array(0) {
308- array(0) {
311+ *** Testing glob() with pattern within braces ***
312+ array(1) {
313+ [0]=>
314+ string(83)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder12345"
312- string(%d) "1"
316+
317+ *** Testing glob() on directories ***
318+ -- Iteration 1 --
319+ array(1) {
320+ [0]=>
321+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
318-
319- *** Testing glob() with pattern within braces ***
322- string(%d) "%s/glob_variation/wonder12345"
323+ -- Iteration 2 --
324+ array(1) {
325+ [0]=>
326+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
324-
325- *** Testing glob() on directories ***
326- -- Iteration 1 --
328+ -- Iteration 3 --
331+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
331- -- Iteration 2 --
332- array(1) {
333- [0]=>
334- string(%d) "%s/glob_variation/wonder1"
333+ -- Iteration 4 --
336+ -- Iteration 5 --
336- -- Iteration 3 --
339+ -- Iteration 6 --
342+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
343+ }
344+ -- Iteration 7 --
345+ array(0) {
346+ }
347+ -- Iteration 8 --
348+ bool(false)
349+ -- Iteration 9 --
350+ array(0) {
351+ }
352+ -- Iteration 10 --
353+ array(0) {
355+ -- Iteration 11 --
360+ -- Iteration 12 --
361+ array(0) {
363+ Done
337- array(1) {
338- [0]=>
339- string(%d) "%s/glob_variation/wonder1"
340- }
341- -- Iteration 4 --
342- array(0) {
343- }
344- -- Iteration 5 --
345- array(0) {
346- }
347- -- Iteration 6 --
348- array(1) {
349- [0]=>
350- string(%d) "%s/glob_variation/wonder1"
351- }
352- -- Iteration 7 --
353- array(0) {
354- }
355- -- Iteration 8 --
356- array(0) {
357- }
358- -- Iteration 9 --
359- array(0) {
360- }
361- -- Iteration 10 --
362- array(0) {
363- }
364- -- Iteration 11 --
365- array(1) {
366- [0]=>
367- string(%d) "%s/glob_variation/wonder1"
368- }
369- -- Iteration 12 --
370- array(0) {
371- }
372- Done
Expected result:
test pass
Actual result:
--
test fail
--
Edit this bug report at https://bugs.php.net/bug.php?id=61667&edit=1
[PHP-BUG] Bug #61667 [NEW]: ext\standard\tests\file\glob_variation-win32.phpt fails
From: ab
Operating system: windows
PHP version: 5.3.10
Package: Filesystem function related
Bug Type: Bug
Bug description:ext\standard\tests\file\glob_variation-win32.phpt fails
Description:
Test diff:
240+ bool(false)
241+ bool(false)
242+ bool(false)
243+ bool(false)
244+ bool(false)
245+ bool(false)
246+
247+ -- Iteration 9 --
248- string(%d) "%s/glob_variation/WONDER5"
255- -- Iteration 9 --
256+ string(33) "$file_path/glob_variation/wonder5"
263+ -- Iteration 10 --
264- string(%d) "$file_path/glob_variation/wonder5"
271- -- Iteration 10 --
272+ string(80)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/?wonder?"
279+ -- Iteration 11 --
280- string(%d) "%s/glob_variation/?wonder?"
287- -- Iteration 11 --
288+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder?"
295+ -- Iteration 12 --
296- string(%d) "%s/glob_variation/wonder?"
303- -- Iteration 12 --
304- array(0) {
304+ string(1) "1"
306- array(0) {
308- array(0) {
311+ *** Testing glob() with pattern within braces ***
312+ array(1) {
313+ [0]=>
314+ string(83)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder12345"
312- string(%d) "1"
316+
317+ *** Testing glob() on directories ***
318+ -- Iteration 1 --
319+ array(1) {
320+ [0]=>
321+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
318-
319- *** Testing glob() with pattern within braces ***
322- string(%d) "%s/glob_variation/wonder12345"
323+ -- Iteration 2 --
324+ array(1) {
325+ [0]=>
326+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
324-
325- *** Testing glob() on directories ***
326- -- Iteration 1 --
328+ -- Iteration 3 --
331+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
331- -- Iteration 2 --
332- array(1) {
333- [0]=>
334- string(%d) "%s/glob_variation/wonder1"
333+ -- Iteration 4 --
336+ -- Iteration 5 --
336- -- Iteration 3 --
339+ -- Iteration 6 --
342+ string(79)
"C:\php-sdk\php53\vc9\x86\php-src\ext\standard\tests\file/glob_variation/wonder1"
343+ }
344+ -- Iteration 7 --
345+ array(0) {
346+ }
347+ -- Iteration 8 --
348+ bool(false)
349+ -- Iteration 9 --
350+ array(0) {
351+ }
352+ -- Iteration 10 --
353+ array(0) {
355+ -- Iteration 11 --
360+ -- Iteration 12 --
361+ array(0) {
363+ Done
337- array(1) {
338- [0]=>
339- string(%d) "%s/glob_variation/wonder1"
340- }
341- -- Iteration 4 --
342- array(0) {
343- }
344- -- Iteration 5 --
345- array(0) {
346- }
347- -- Iteration 6 --
348- array(1) {
349- [0]=>
350- string(%d) "%s/glob_variation/wonder1"
351- }
352- -- Iteration 7 --
353- array(0) {
354- }
355- -- Iteration 8 --
356- array(0) {
357- }
358- -- Iteration 9 --
359- array(0) {
360- }
361- -- Iteration 10 --
362- array(0) {
363- }
364- -- Iteration 11 --
365- array(1) {
366- [0]=>
367- string(%d) "%s/glob_variation/wonder1"
368- }
369- -- Iteration 12 --
370- array(0) {
371- }
372- Done
Expected result:
test pass
Actual result:
--
test fail
--
Edit bug report at https://bugs.php.net/bug.php?id=61667&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61667&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61667&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61667&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61667&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61667&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61667&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61667&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61667&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61667&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61667&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61667&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61667&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61667&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61667&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61667&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61667&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61667&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61667&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61667&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=6
Bug #61666 [Com]: ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61666&edit=1 ID: 61666 Comment by: a...@php.net Reported by:a...@php.net Summary: ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails Status: Open Type: Bug Package:Filesystem function related Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: the warning for \0 isn't issued but an early return false is done, so just adopted the expected value Previous Comments: [2012-04-08 10:25:20] a...@php.net The following patch has been added/updated: Patch Name: 61666.diff Revision: 1333880720 URL: https://bugs.php.net/patch-display.php?bug=61666&patch=61666.diff&revision=1333880720 [2012-04-08 10:23:35] a...@php.net Description: Test diff: 030- 031- Warning: file_put_contents(): Filename cannot be empty in %s on line %d: file_put_contents(): Filename cannot be empty in %s on line %d The test fails on PHP 5.3 only Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61666&edit=1
Bug #61666 [PATCH]: ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails
Edit report at https://bugs.php.net/bug.php?id=61666&edit=1 ID: 61666 Patch added by: a...@php.net Reported by:a...@php.net Summary: ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails Status: Open Type: Bug Package:Filesystem function related Operating System: Windows PHP Version:5.3.10 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: 61666.diff Revision: 1333880720 URL: https://bugs.php.net/patch-display.php?bug=61666&patch=61666.diff&revision=1333880720 Previous Comments: [2012-04-08 10:23:35] a...@php.net Description: Test diff: 030- 031- Warning: file_put_contents(): Filename cannot be empty in %s on line %d: file_put_contents(): Filename cannot be empty in %s on line %d The test fails on PHP 5.3 only Expected result: test pass Actual result: -- test fail -- Edit this bug report at https://bugs.php.net/bug.php?id=61666&edit=1
[PHP-BUG] Bug #61666 [NEW]: ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails
From: ab Operating system: Windows PHP version: 5.3.10 Package: Filesystem function related Bug Type: Bug Bug description:ext\standard\tests\file\file_put_contents_variation8-win32.phpt fails Description: Test diff: 030- 031- Warning: file_put_contents(): Filename cannot be empty in %s on line %d: file_put_contents(): Filename cannot be empty in %s on line %d The test fails on PHP 5.3 only Expected result: test pass Actual result: -- test fail -- Edit bug report at https://bugs.php.net/bug.php?id=61666&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61666&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61666&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61666&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61666&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61666&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61666&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61666&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61666&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61666&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61666&r=support Expected behavior: https://bugs.php.net/fix.php?id=61666&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61666&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61666&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61666&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61666&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61666&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61666&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61666&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61666&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61666&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61666&r=mysqlcfg
Bug #61660 [Com]: bin2hex(hex2bin($data)) != $data
Edit report at https://bugs.php.net/bug.php?id=61660&edit=1
ID: 61660
Comment by: krtek4+php at gmail dot com
Reported by:krtek4+php at gmail dot com
Summary:bin2hex(hex2bin($data)) != $data
Status: Open
Type: Bug
Package:*General Issues
Operating System: Debian Linux
PHP Version:5.4.1RC1
Block user comment: N
Private report: N
New Comment:
If I could intervene, my patch does exactly the same thing without adding a new
test for each iteration of the loop.
Mine has only one modulo (%) outside of the loop and the new test is executed
only
once at the first pass assuming the string is a correct hexadecimal value.
Like said in your last comment, the % operation can even be optimized with a '&
1'
if needed.
Previous Comments:
[2012-04-08 10:01:22] larue...@php.net
@theanomaly as we talked, since Rasmus said it's okey, then I have no objection.
2 suggestions :
1. use oddlen & 1 instead of oddlen % 2
2. since you cal oddlen % 2 twice, so it's better if you can use a var to hold
it
and it's better for you to make a pull request by yourself, let me know if you
need help on that :)
[2012-04-08 10:00:43] krtek4+php at gmail dot com
The internal representation must always be aligned on 8 bits, thus we have no
choice to pad with 0 bits at the beginning, 1000 and 1000 is the exact same
value in binary and I think the actual patch is correct.
The new problem is that the reverse operation, i.e. bin2hex, should remove the
added 0 bit at the beginning.
@theanomaly ; decbin works just fine since it returns a string composed of 0s
and 1s and not a "binary value". hex2bin / bin2hex are the only function I'm
aware of working this way.
BTW, why did you sent another patch ? mine is doing exactly the same as yours
and is working fine.
[2012-04-08 09:42:25] theanomaly dot is at gmail dot com
@laruence
I've replaced the last patch with a better patch because I realized I created a
memory leak and that was a poor strategy.
I can't understand why there should be any confusion about whether it's an
octal
value or a hexadecimal value though. Since when should using bin2hex() ever
leave us with the expectation that would _ever_ get back an octal value?
I might be missing something here, but hex2bin() should always be expecting a
hexadecimal value and bin2hex() should always leave us with the expectation of
a
hexadecimal value. I see nothing wrong with padding the value to an even number
otherwise the result is hex2bin() isn't doing what it's supposed to be doing.
It
makes sense to me that even if the client sends a value of '1' that it's
completely expected behavior that '01' and '1' should both be a valid
hexadecimal value.
To me it just makes no sense to punish the client for forgetting to pad the
value by returning false data. At the very least we should be issuing a warning
to let the client know they have sent unexpected data and then this can be
documented behavior. But why waste time fixing it to issue E_WARNINGs when this
patch fixes the issue completely? Besides hex2bin is returning a string. It's
not like the user can inadvertently use it as an octal value.
var_dump('0123' + '0123'); // int(246)
This would be silly not to fix in my opinion. Especially since it's such an
easy
fix. At least run the patch and let me know which test case you can come up
with
that would break any of PHP's already existing documented behavior by making
this modification?
[2012-04-08 08:07:32] larue...@php.net
@theanomaly I have tried the similar way as you did. but the key problem is
the
result will be considered as a oct number.
reads:
"123" != "0123"
[2012-04-08 04:38:44] theanomaly dot is at gmail dot com
I've also submitted a patch which seems to work fine as far as I've tested it.
Similar to the previous patch, but mine simply prepends a 0 to the beginning of
every odd length string sent to hex2bin. It shouldn't break anything that I can
see. If anything it just ensures we always have a valid hexadecimal
representation since the implementation relies on shift 1 to translate between
hex and binary (we'll always be one off). I suggest this also becomes a part of
the dec2bin implementation since it would make sense to return a full octet in
that representation as well. Sorry if my patch looks ugly though. This is my
first attempt at a patch.
The remainder of the comments for this report are too long. To view
the rest of the comment
[PHP-BUG] Bug #61665 [NEW]: include on stream wrapper results in wsod
From: Operating system: Ubuntu 10.04 PHP version: 5.3.10 Package: Streams related Bug Type: Bug Bug description:include on stream wrapper results in wsod Description: Hi, I am currently running a drupal website using a module (http://drupal.org/project/configuration) that provided its own contributed stream wrapper to find the local configuration directory (so it was in the format 'config://path/to/file' - the implementation can be seen at http://drupalcode.org/project/configuration.git/blob/refs/heads/7.x-1.x:/configuration_stream.inc). On my local environment of running the site with the module (which runs php 5.3.6), the configuration would be able to scan on files with the protocol without any issues. However, once I moved to my staging environment which runs php 5.3.10, I would end up with a wsod. The strange part was that the page returned a code 200 and nothing in the error log. I made sure that allow_url_fopen was enabled and the protocols actually registered so it should have worked correctly. Moreover, using file_exists and is_file work to ensure the file exists so that meant the file was being found the first time around. For now, my workaround has been to use drupal's functions to get the stream converted correctly (see http://drupal.org/files/config-stream.patch as my workaround for the module to work) but problem seems to stem from PHP which is why I am filing my issue here. Any help that can be provided would be greatly appreciated. Test script: --- Implement a simple stream wrapper to a file in local (lets call it local). Create a php file to include from somewhere (called test_include.inc). Have the line 'include local://path/to/test_include.inc'. Expected result: It should result in a code 200 but also a wsod. Actual result: -- The script should be correctly included. -- Edit bug report at https://bugs.php.net/bug.php?id=61665&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61665&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61665&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61665&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61665&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61665&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61665&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61665&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61665&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61665&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61665&r=support Expected behavior: https://bugs.php.net/fix.php?id=61665&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61665&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61665&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61665&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61665&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61665&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61665&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61665&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61665&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61665&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61665&r=mysqlcfg
Bug #54233 [Com]: PHP Filter email doesn't work properly
Edit report at https://bugs.php.net/bug.php?id=54233&edit=1 ID: 54233 Comment by: michael at squiloople dot com Reported by:flood at itnews-bg dot com Summary:PHP Filter email doesn't work properly Status: Open Type: Bug Package:Filter related Operating System: Slackware 13x86_64 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: That is a valid email address. "?", "'" and "_", ".", as well as letters and numbers are acceptable characters in an email address's local-part. carsten_sttgt at gmx dot de, it uses RFC 5321 (more or less). Previous Comments: [2011-03-12 12:14:02] carsten_sttgt at gmx dot de That's the correct behavior. FILTER_SANITIZE_EMAIL on: ?â?â°?âaâ¬?â?S?âaâ¬_?âaâ¬??âaâ¬Â¦?â??' this.is.a.test...@email.com results in: ???a??S?a_?a??a???'this.is.a.test...@email.com and that's a valid email address according to (at least) RFC822 (sorry, don't know which RFC PHP is exactly using for FILTER_VALIDATE_EMAIL. Should be documented) [2011-03-11 22:44:21] flood at itnews-bg dot com Hey, It seems the filter function is not working some times. You can see in the test script that the email is returned as a valid though it's not quite. [2011-03-11 22:43:36] flood at itnews-bg dot com Description: Hey, It seems the filter function is not working some times. You can see in the test script that the email is returned as a valid though it's not quite. Testing script: Test script: --- Expected result: It should return a false boolean. This is not a valid email. Actual result: -- Returns an invalid email: ???a??S?a_?a??a???'this.is.a.test...@email.com -- Edit this bug report at https://bugs.php.net/bug.php?id=54233&edit=1
