date:20131024

Bug #65550 [Com]: get_browser() incorrectly parsers entries with "+" sign.

2013-10-24 Thread oliver at realtsp dot com

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

 ID: 65550
 Comment by: oliver at realtsp dot com
 Reported by:quentin389 at gmail dot com
 Summary:get_browser() incorrectly parsers entries with "+"
 sign.
 Status: Open
 Type:   Bug
 Package:Unknown/Other Function
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this bug on php 5.4.14 using this browscap file:
http://tempdownloads.browserscap.com/stream.asp?PHP_BrowsCapINI

"Mozilla/5.0 (compatible; AhrefsBot/5.0; +http://ahrefs.com/robot/)"

is not recognised


Previous Comments:

[2013-08-25 15:27:57] quentin389 at gmail dot com

Description:

get_browser() incorrectly handles entries from browscap.ini files when they 
have "+" sign in the pattern match. The "+" in the ini files is a LITERAL 
character, not a wildcard match. The only wildcard that browscap.ini source 
files use are "*" and "?".
The result of that is that none of the browscap.ini entries that have a match 
pattern with "+" ever match the browsers that they are supposed to match.

My suspicion is that if you'd change 
https://github.com/php/php-src/blob/master/ext/standard/browscap.c#L110 and add:

case '+':
  t[j++] = '\\';
  t[j] = '+';
  break;

everything would be fixed. But I haven't tested that.

Test script:
---
// browscap.ini entry:
// [Mozilla/5.0 (compatible; AhrefsBot/*; +http://ahrefs.com/robot/)]
// Parent="Search Engines"
// Browser="AhrefsBot"

echo "";
var_dump(get_browser('Mozilla/5.0 (compatible; AhrefsBot/4.0; 
+http://ahrefs.com/robot/)'));


Expected result:

object(stdClass)#2 (35) {
  (...)
  ["Browser"]=>
  string(9) "AhrefsBot"


Actual result:
--
object(stdClass)#1 (34) {
  (...)
  ["browser"]=>
  string(15) "Default Browser"







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

Bug #63355 [Opn->Fbk]: PHP 5.3.x failes with core dump

2013-10-24 Thread yohgaki

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

 ID: 63355
 Updated by: yohg...@php.net
 Reported by:rainer dot herbst at uni-potsdam dot de
 Summary:PHP 5.3.x failes with core dump
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Solaris 10 SPARC
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

Since we don't fix bugs in 5.3, could you try to see if 5.4 or later segfaults.


Previous Comments:

[2012-11-12 14:25:39] rainer dot herbst at uni-potsdam dot de

The core dumps with the "zend_hash_find" problem occure when APC is disabled. 
With APC enabled, we find "zend_vm_stack_alloc" in the core dumps.


[2012-11-12 13:36:02] johan...@php.net

Does this also happen without APC? Any chance to get som ereproduce code? hard 
to identify otherwise.


[2012-11-12 09:46:05] rainer dot herbst at uni-potsdam dot de

Disabling APC does not solve the Problem. In both php 5.3. and 5.4 we still 
receive core dumps like this:

core '/var/cores/n-moodle2-6.1352712335.24296.httpd' of 24296:  
/opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co
 fe09de40 zend_hash_find (fe646b24, 21b888, 25, ffbff180, ff, 6f646c65) + 50
 fe018e10 zend_set_compiled_filename (21b888, 2252, ffbff1f8, 21ba68, 24, 0) + 
48
 fdfdbabc open_file_for_scanning (ffbff4c8, 1, ffc0, 21b888, 0, 0) + 304
 fdfdbbec compile_file (ffbff4c8, 2, 0, 0, 21b7c8, 21b7c8) + 94
 fd9a20f0 phar_compile_file (ffbff4c8, 2, ffc0, 80, 540ba4, 48) + 3b8
 fe07e7e8 zend_execute_scripts (2, 0, 1, ffbff4c8, 70687000, 7068702d) + 140
 fe19e6dc php_handler (53ee28, e1, 0, 1231d8, 127920, 0) + 74c
 0005c534 ap_run_handler (53ee28, 53f9f0, 0, 1413b8, , 1) + 8c
 0005d1c4 ap_invoke_handler (53ee28, 0, 53ede8, 0, 0, 0) + 154
 0007da90 ap_process_async_request (53ee28, 0, 4, 4b0870, 0, 4) + 488
 0007dba4 ap_process_request (53ee28, 4, 53ee28, 53fa50, 0, 4b0870) + 24
 00078edc ap_process_http_sync_connection (4b0870, 4b0b20, 0, 4b05d8, 53ee28, 
4b0b08) + 7c
 0007903c ap_process_http_connection (4b0870, 4b05d8, 4b05d8, 4b0b20, 0, 0) + 64
 0006c1f4 ap_run_process_connection (4b0870, 4b05d8, 4b05d8, 1416f0, , 
0) + 8c
 0006c8c8 ap_process_connection (4b0870, 4b05d8, 4b05d8, 14, 4ae638, 4b45a8) + 
60
 0008746c child_main (14, 86398, 0, da6d8, 4b0870, 0) + 93c
 0008775c make_child (dfd18, 14, 0, 0, 1cf4, fefb6100) + 1f4
 00087820 startup_children (20, 2, 97fe4, 1415f8, 14, 1) + 90
 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254
 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, , 0) + 9c
 0002e01c main (5, ffbffd4c, ffbffd64, ac800, ff0e0100, 0) + 12ec
 0002ba38 _start   (0, 0, 0, 0, 0, 0) + d8


zend_hash_find is quite a short function, so it should not be so difficult to 
find the reason for this annoying instability...


[2012-10-30 12:01:18] rainer dot herbst at uni-potsdam dot de

Compiled the latest APC version (3.1.13), but same behaviour:
- core dumps with
fe256d98 zend_vm_stack_alloc (1040, ffbff478, fe222de8, 0, 0, 0) + 110
- Service brought to maintenance modus every now and than.


[2012-10-25 23:44:12] s...@php.net

As seems to be usual with cases involving APC, try to reproduce it _without_ 
APC.
You might also care to try the latest APC, though most of its fixes are 
probably 
for PHP 5.4.  

Thanks for the report but a testcase is really 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=63355


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

Bug #63510 [Asn->Opn]: Integer overflow with chr

2013-10-24 Thread yohgaki

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

 ID: 63510
 Updated by: yohg...@php.net
 Reported by:idokan at gmail dot com
 Summary:Integer overflow with chr
-Status: Assigned
+Status: Open
 Type:   Bug
 Package:Strings related
 PHP Version:5.4.8
 Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2012-11-14 15:36:32] idokan at gmail dot com

Huh ?!

ASCII is 0..127 chars, if they are out of range and also from extended ASCII 
(128..255), then you must report an error like with normal implementation such 
as Ruby, Python, Pascal, Perl (with strict bytes) etc...
Not to $value & 255 it.


[2012-11-14 15:28:28] larue...@php.net

I think this check could be done in user script self.

the document said:
chr convert *ascii* code .. so...


[2012-11-14 09:36:12] idokan at gmail dot com

Description:

The chr function translate a single Byte length integer into it's ASCII value.
When providing a number bigger then 255, it returns the first byte instead of 
reporting an error about being out of range.

Test script:
---
echo chr(1000) . ' ' . ord(chr(1000)) . "\n";

Expected result:

chr must check the numeric boundaries and report on on an error when they are 
out of the range.

Actual result:
--
returns the first byte out of the result, making it appear like an integer 
overflow that the carry flag exception was captured.






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

Bug #65905 [Com]: [16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: Unknown: No such file or dir

2013-10-24 Thread spam2 at rhsoft dot net

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

 ID: 65905
 Comment by: spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: 
 Unknown: No such file or dir
 Status: No Feedback
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4.20
 Block user comment: N
 Private report: N

 New Comment:

WHAT FEEDBACK?

do you guys really not realize that the problem is the lacking knowledge of the 
involved script and so if i could give fedback the problem would not exist?


Previous Comments:

[2013-10-24 04:05:01] php-bugs at lists dot php dot net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.


[2013-10-17 05:04:01] spam2 at rhsoft dot net

> Not enough information was provided for us to be able to handle this bug

explain me how should i get more information?
*i need* more information from this damned error hanlder to handle *my bug* in 
one of 50 files

the error-handler has in *any case* contain the information of the affected 
script which is obviously thrown away - how comes that __FILE__ of the 
originally called script is thrown away and the error-handler only becomes a 
completly useless "in unknown"

so there are two choices:
* fi the error handler / scripting language that it contains informations
* shut up the error-hanlder in cases it has nothing useful to say

the whole error-reporting is broken
give out script names or shut up at all!

https://bugs.php.net/bug.php?id=65359
https://bugs.php.net/bug.php?id=65455


[2013-10-16 22:48:45] s...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


Perhaps someone marked your other bug as 'spam' due to inappropriate content? I 
don't know. Anyway, I think you've made your point.

If you want some PHP language change to be made, please submit a testcase so we 
know exactly what is bugging you.

(If you have an application architectural issue, there are better places to 
resolve it than by logging a bug)


[2013-10-15 23:35:24] spam2 at rhsoft dot net

Description:

you can call it as spam and request sample-code as often you want
*this* is fundamentally broken and if i would have a clue wich of some thousand 
scripts was triggred by a smarter error message i would be able to fix it

[16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning:  Unknown: No such file or 
directory in Unknown on line 0

PHP's whole error-handling is broken!
why? because it is *unacceptable* that the information which script was 
initailly called is thrown away before the error-handler and this happens on 
serveral places

Expected result:

at least the full qualified path of the inital script called on the server and 
in this case also the not found filename which was supplied and if you are so 
gently the called function too (fopen, fwrite, file.)

Actual result:
--
unknown in unknown on unknown






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

Bug #65955 [Csd]: Invalid Json response

2013-10-24 Thread yohgaki

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

 ID: 65955
 Updated by: yohg...@php.net
 Reported by:aaatoja at o2 dot pl
 Summary:Invalid Json response
 Status: Closed
 Type:   Bug
 Package:PDO related
 Operating System:   Linux Ubuntu
 PHP Version:5.4.21
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

Do you mean fixed in 5.5, but not 5.4? Then this should be re-opened.


Previous Comments:

[2013-10-24 10:26:29] aaatoja at o2 dot pl

I see bug is fixed in v5.5.


[2013-10-24 07:31:37] aaatoja at o2 dot pl

Description:

I have a Postgresql (v9.3) view which contains column made from json_agg() 
function (array_agg works fine).
My response looks like:
array(5) {
  [0] => array(2) {
["aggcolumn"] => NULL
[0] => NULL
  }
  [1] => array(2) {
["aggcolumn"] => string(14) "["test"]]"
[0] => string(14) "["test"]]"
  }
  [2] => array(2) {
["aggcolumn"] => string(34) "["test", "test2"]]]"
[0] => string(34) "["test", "test2"]]]"
  }
  [3] => array(2) {
["aggcolumn"] => string(26) "["test3""
[0] => string(26) "["test3""
  }
  [4] => array(2) {
["aggcolumn"] => string(46) "["test2", "test3"]"
[0] => string(46) "["test2", "test3"]"
  }
}

Test script:
---
try {
$dbh = new PDO($dsn, $user, $password);
$sth = $dbh->prepare('SELECT aggcolumn FROM view_test WHERE 
company_id = ? AND active_flag IS TRUE');
$sth->execute(array(10));
$res = $sth->fetchAll();
var_dump($res);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e->getMessage();
}

Expected result:

Response should be valid JSON string.

Actual result:
--
As You may notice every row has a value with an extra ']' at the end, based on 
current iteration count. That makes string invalid JSON response






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

Req #27205 [Opn->Csd]: fnmatch support for windows

2013-10-24 Thread yohgaki

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

 ID: 27205
 Updated by: yohg...@php.net
 Reported by:omri at magniv dot org
 Summary:fnmatch support for windows
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Windows 2003
 PHP Version:4.3.4
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

Implemented


Previous Comments:

[2004-02-10 07:12:36] omri at magniv dot org

Description:

Currently, fnmatch is not supported under windows systems.
Is it possible to support it?
I know it's possible, I've seen some windows apps that use it.







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

Bug #49874 [Opn]: ftell() and fseek() inconsistency when using stream filters

2013-10-24 Thread yohgaki

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

 ID: 49874
 Updated by: yohg...@php.net
 Reported by:jketterl at chipxonio dot de
 Summary:ftell() and fseek() inconsistency when using stream
 filters
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   linux (ubuntu)
-PHP Version:5.2.11
+PHP Version:5.5.4
 Block user comment: N
 Private report: N

 New Comment:

It seems 5.5 has this problem still

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(5) "e 01
"
[yohgaki@dev php-5.4]$ php -v
PHP 5.5.4 (cli) (built: Sep 19 2013 13:06:40)


Previous Comments:

[2009-10-15 06:54:31] jketterl at chipxonio dot de

thanks for having a look

i tried with and without. the challenge is to get it working without, because 
that's the worst case my app has to deal with, but the BOM doesn't seem to 
solve this.

$ hexdump test-with-bom.csv
000 feff 004c 0069 006e 0065 0020 0030 0031
010 000a 004c 0069 006e 0065 0020 0030 0032
020 000a 004c 0069 006e 0065 0020 0030 0033
030 000a 004c 0069 006e 0065 0020 0030 0034
040 000a
042

$ php test.php
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(5) "e 01
"

i also tried opening the file including the BOM without a stream filter, but 
that just resulted in php reading in two extra chars (the BOM converted in some 
way i guess) on the beginning of the first line.

i thought i'd attach the sample files to this bug, but it seems like i can't. 
i've uploaded them here instead: http://www.djmacgyver.net/tmp/php-ftell/


[2009-10-14 16:40:00] sjo...@php.net

Thank you for your bug report. Does your test.csv file start with a BOM? You 
can determine this by viewing the file in a hex editor. If it starts with fffe 
or feff, it has a BOM (byte order mark).


[2009-10-14 11:39:39] jketterl at chipxonio dot de

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli) (built: 
Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be easier 
to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into iso8859 (or 
most probably from any 2byte-encoded charset into any single-byte-encode 
charset) the ftell() and fseek() functions start to behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the 2byte-encoding, 
whereas ftell() seems to return the number of bytes read *after* the filter has 
been applied. thus it is not possible to fseek() back to a certain offset that 
has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(8) "Line 02
"

Actual result:
--
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(4) " 01
"






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

[PHP-BUG] Bug #65947 [NEW]: basename is no more working after fgetcsv in certain situation

2013-10-24 Thread phpbugs at dev dot bitadept dot org

From: phpbugs at dev dot bitadept dot org
Operating system: Gentoo Linux
PHP version:  5.5.5
Package:  Filesystem function related
Bug Type: Bug
Bug description:basename is no more working after fgetcsv in certain situation

Description:

Calls to basename and pathinfo are no more working after using fgetcsv.

This is the case when the system's locale is set to utf8 an you try to
parse a file using fgetcsv that is encoding in iso8859-1 and contains
some german Umlaute.

Setting the locale to iso8859-1 in the first place is fixing the
problem, but this should not happen at all.

System information:
$ uname -a
Linux Merlin 3.5.4-hardened-r1 #2 SMP Mon Jan 21 09:21:26 CET 2013
x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux

$ locale
LANG=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=de_DE.UTF-8

$ php -v
PHP 5.5.5-pl0-gentoo (cli) (built: Oct 22 2013 15:56:09) 
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies


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

[PHP-BUG] Bug #65955 [NEW]: Invalid Json response

2013-10-24 Thread aaatoja at o2 dot pl

From: aaatoja at o2 dot pl
Operating system: Linux Ubuntu
PHP version:  5.4.21
Package:  PostgreSQL related
Bug Type: Bug
Bug description:Invalid Json response

Description:

I have a Postgresql (v9.3) view which contains column made from
json_agg() function (array_agg works fine).
My response looks like:
array(5) {
  [0] => array(2) {
["aggcolumn"] => NULL
[0] => NULL
  }
  [1] => array(2) {
["aggcolumn"] => string(14) "["test"]]"
[0] => string(14) "["test"]]"
  }
  [2] => array(2) {
["aggcolumn"] => string(34) "["test", "test2"]]]"
[0] => string(34) "["test", "test2"]]]"
  }
  [3] => array(2) {
["aggcolumn"] => string(26) "["test3""
[0] => string(26) "["test3""
  }
  [4] => array(2) {
["aggcolumn"] => string(46) "["test2", "test3"]"
[0] => string(46) "["test2", "test3"]"
  }
}

Test script:
---
try {
$dbh = new PDO($dsn, $user, $password);
$sth = $dbh->prepare('SELECT aggcolumn FROM view_test WHERE
company_id = ? AND active_flag IS TRUE');
$sth->execute(array(10));
$res = $sth->fetchAll();
var_dump($res);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e->getMessage();
}

Expected result:

Response should be valid JSON string.

Actual result:
--
As You may notice every row has a value with an extra ']' at the end,
based on current iteration count. That makes string invalid JSON
response

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

Req #45927 [Opn->Csd]: man page spelling errors, misused minus signs, and bad whatis entriewds

2013-10-24 Thread yohgaki

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

 ID: 45927
 Updated by: yohg...@php.net
 Reported by:atomo64 at gmail dot com
 Summary:man page spelling errors, misused minus signs, and
 bad whatis entriewds
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:CGI/CLI related
 PHP Version:5.2.6
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2008-11-05 09:50:47] vr...@php.net

Manual pages are part of the source code.


[2008-08-26 17:48:54] atomo64 at gmail dot com

Description:

sapi/cli/php.1.in, scripts/man1/php-config.1.in, and 
scripts/man1/phpize.1.in all have bad whatis entries (i.e. whatis 
 won't display the whatis information from the man 
page). And there are a couple of typos and misused minus signs in 
sapi/cli/php.1.in

The patch for the first issue can be found at:
http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/bad_whatis_entries.patch?rev=1127&view=markup
And the other patch for the second issue can be found at:
http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/manpage_spelling.patch?rev=1038&view=markup








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

Bug #51846 [Opn->Csd]: SimpleXMLElement iterator produces unexpected results

2013-10-24 Thread yohgaki

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

 ID: 51846
 Updated by: yohg...@php.net
 Reported by:henning at glatter-gotz dot com
 Summary:SimpleXMLElement iterator produces unexpected
 results
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SimpleXML related
 Operating System:   windows xp / Linux
 PHP Version:5.3.2
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

It seems fixed already at least on my 5.5.4/linux.


Previous Comments:

[2010-05-18 17:40:07] henning at glatter-gotz dot com

I agree, it is possible that this is indeed related or even the same
problem as 50670. I ran some more test on documents with more than
10k elements and there both of my test cases fail, even the one that
works for smaller sets.

Did not think to look for issues related to the script Engine, so I
did not find that bug.

Maybe you can mark this one as a dupe and I will vote on the 50670.

Thanks!


[2010-05-18 09:39:55] m...@php.net

Probably related to Bug #50670


[2010-05-18 03:15:02] henning at glatter-gotz dot com

For windows I downloaded the latest available VC6 x86 Thread Safe (2010-Mar-04 
20:11:08) binaries, and tried it (see original report).
I cannot build from Source on Linux, I do not have sufficient access to a 
system 
to do that. Sorry.
But I did test on two different OS' and 3 different versions of PHP.


[2010-05-18 02:58:11] fel...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




[2010-05-18 02:56:11] henning at glatter-gotz dot com

Added Linux (Ubuntu) to the OS field.




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


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

Bug #54612 [Opn->Fbk]: random Error 404

2013-10-24 Thread yohgaki

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

 ID: 54612
 Updated by: yohg...@php.net
 Reported by:erno dot kovacs at freemail dot hu
 Summary:random Error 404
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

Do you still have problem with 5.4 or later?


Previous Comments:

[2011-10-08 14:33:59] f...@php.net

This is not related to FPM. 

I move this bug to core.


[2011-09-07 16:28:41] erno dot kovacs at freemail dot hu

php_resolve_path is being called with the correct filename, which is
/web/web/xx/index.php this time, and at the tsrm_realpath() call and then 
it fails somewhere in virtual_file_ex, where it failes at this block:

add_slash = (use_realpath != CWD_REALPATH) && path_length > 0 && 
IS_SLASH(resolved_path[path_length-1]);
t = CWDG(realpath_cache_ttl) ? 0 : -1;
path_length = tsrm_realpath_r(resolved_path, start, path_length, &ll, 
&t, use_realpath, 0, NULL TSRMLS_CC);

if (path_length < 0) {
errno = ENOENT;
 mydebug("VFEX FAILURE #444");
return 1;
}

i dont want to dig any deeper, please give me some hints.


[2011-09-07 15:47:50] erno dot kovacs at freemail dot hu

Added a few lines of dummy debug info into fopen_wrappers's 
php_fopen_primary_script, and when it fails, it fails at
zend_resolve_path(), which returns NULL.


[2011-09-07 15:13:24] erno dot kovacs at freemail dot hu

got the same issue on another box (debian lenny this time, not squeeze) with 
php 5.3.8, here are the logs:

when its ok:
# strace -s 1024 -p 27057
Process 27057 attached - interrupt to quit
accept(0, {sa_family=AF_INET, sin_port=htons(47532), 
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4
clock_gettime(CLOCK_MONOTONIC, {67474521, 156597098}) = 0
time(NULL)  = 1315407924
times({tms_utime=37, tms_stime=14, tms_cutime=0, tms_cstime=0}) = -123996470
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}])
read(4, "\1\1\0\1\0\10\0\0"..., 8)  = 8
read(4, "\0\1\0\0\0\0\0\0"..., 8)   = 8
read(4, "\1\4\0\1\3\2\0\0"..., 8)   = 8
read(4, 
"\17\17SERVER_SOFTWARElighttpd/1.4.29\v\nSERVER_NAMExx.com\21\7GATEWAY_INTERFACECGI/1.1\v\5SERVER_PORT50001\v\fSERVER_ADDR217.13.99.87\v\5REMOTE_PORT51194\v\fREMOTE_ADDR80.98.95.222\v\nSCRIPT_NAME/index.php\t\0PATH_INFO\17\31SCRIPT_FILENAME/web/web/xx/index.php\r\20DOCUMENT_ROOT/web/web/xx/\v\1REQUEST_URI/\f\0QUERY_STRING\16\3REQUEST_METHODGET\17\3REDIRECT_STATUS200\17\10SERVER_PROTOCOLHTTP/1.1\t\20HTTP_HOSTxx.com:50001\17JHTTP_USER_AGENTMozilla/5.0
 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20100101 
Firefox/6.0.1\v?HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\24#HTTP_ACCEPT_LANGUAGEhu-hu,hu;q=0.8,en-us;q=0.5,en;q=0.3\24\rHTTP_ACCEPT_ENCODINGgzip,
 
deflate\23\36HTTP_ACCEPT_CHARSETISO-8859-2,utf-8;q=0.7,*;q=0.7\10\1HTTP_DNT1\17\nHTTP_CONNECTIONkeep-alive\22\tHTTP_CACHE_CONTROLmax-age=0"...,
 770) = 770
read(4, "\1\4\0\1\0\0\0\0"..., 8)   = 8
clock_gettime(CLOCK_MONOTONIC, {67474521, 161587774}) = 0
time(NULL)  = 1315407924
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={60, 0}}, NULL) = 0
rt_sigaction(SIGPROF, {0x8229650, [PROF], SA_RESTART}, {0x8229650, [PROF], 
SA_RESTART}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
time(NULL)  = 1315407924
lstat64("/web/web/xx/index.php", {st_mode=S_IFREG|0644, st_size=7076, ...}) 
= 0
lstat64("/web/web/xx", {st_mode=S_IFDIR|0755, st_size=108, ...}) = 0
lstat64("/web/web", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
readlink("/web/web", "/"..., 4096)  = 1
open("/xx/index.php", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
clock_gettime(CLOCK_MONOTONIC, {67474521, 168395023}) = 0
getcwd("/"..., 4095)= 2
chdir("/web/web/xx")= 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={120, 0}}, NULL) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfa293b8) = -1 ENOTTY (Inappropriate 
ioctl for device)
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
mmap2(NULL, 7108, PROT_READ, MAP_PRIVATE, 5, 0) = 0xb5168000
fstat64(5, {st_mode=S_IFREG|0644, st_size=7076, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb5167000
_llseek(5, 0, [0], SEEK_CUR)= 0
munmap(0xb5168000, 7076)= 0
close(5)= 0
munmap(0

[PHP-BUG] Bug #65945 [NEW]: Nested use of pdo->prepare()->execute clears the outer resultset-object

2013-10-24 Thread news at franky dot net

From: news at franky dot net
Operating system: Mac OS X 10.8.5
PHP version:  5.4.21
Package:  PDO related
Bug Type: Bug
Bug description:Nested use of pdo->prepare()->execute clears the outer 
resultset-object

Description:

In PHP 5.3 the test script works fine and gives me the results as you
see in "expected result".

If i use PHP 5.4 or PHP 5.5, the inner pdo->prepare()->execute clears
the outer PDO-Resultset unexpectedly.

Test script:
---
$pdo = new PDO("dblib:host=192.168.1.100;dbname=kunden;charset=UTF-8;",
"kunden", "geheim");

$stmt = $pdo->prepare("select top 10 * from Kunden");
$stmt->execute();

while($row = $stmt->fetch()) {
echo 'KundenID: ' . $row["KundenID"] . '';

$stmt2 = $pdo->prepare("select top 10 * from Ansprechpartner where
KundenID=?");
$stmt2->execute(array($row["KundenID"]));

while($row2 = $stmt2->fetch()) {
echo 'AnsprechpartnerID: ' . $row2["AnsprechpartnerID"] . '';
}

}

unset($pdo);

Expected result:

KundenID: 10
AnsprechpartnerID: 1624
AnsprechpartnerID: 1716
AnsprechpartnerID: 7823
AnsprechpartnerID: 9309
AnsprechpartnerID: 10398
AnsprechpartnerID: 18686
KundenID: 13
AnsprechpartnerID: 1621
KundenID: 15
AnsprechpartnerID: 1596
AnsprechpartnerID: 4769
AnsprechpartnerID: 92891

Actual result:
--
KundenID: 10
AnsprechpartnerID: 1624
AnsprechpartnerID: 1716
AnsprechpartnerID: 7823
AnsprechpartnerID: 9309
AnsprechpartnerID: 10398
AnsprechpartnerID: 18686

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

Bug #52598 [Opn->Csd]: zend_mm_heap corrupted

2013-10-24 Thread yohgaki

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

 ID: 52598
 Updated by: yohg...@php.net
 Reported by:dr4k0n at list dot ru
 Summary:zend_mm_heap corrupted
-Status: Open
+Status: Closed
 Type:   Bug
 Package:*General Issues
 Operating System:   Gentoo Linux 2.6.34-xenU-fly
 PHP Version:5.2.14
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2010-12-06 22:18:35] wdierkes at rackspace dot com

Just following up with this again.  This issue is still in the 'open' status.  
I 
understand that 5.2.14 was the last PHP 5.2 release... which makes it even more 
important for the developers to follow up and help us locate where this issue 
was fixed in SVN (commit number)... so that we can produce a patch and backport 
it to our packages.

I attempted to contact Felipe directly, however that email address is either 
bogus or no longer available.

We have customers affected by this bug that we are attempting to backport for.

As always, thank you for your time!


[2010-09-24 21:13:52] wdierkes at rackspace dot com

Can we please get the SVN commit revision that this was fixed in?  I've tried 
searching the log, but I see no reference to '52598' or 'zend_mm_heap'.  Thank 
you.


[2010-08-23 16:11:52] andy at blyler dot cc

What SVN revision(s) was this fixed in?


[2010-08-13 10:29:06] felipe at xyz dot com

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.


[2010-08-13 09:26:35] dr4k0n at list dot ru

Description:

I seen "zend_mm_heap corrupted" message after CLI script executed. It's appear 
after some changes in PHP scripts.
Package configuration:
pecl-apc-3.0.19
pecl-memcached-1.0.2
pecl-gearman-0.7.0
libmemcached-0.39

I get valgrind log through command:
export USE_ZEND_ALLOC=0 
valgrind --tool=memcheck --num-callers=30 --log-file=/home/drakon/php_debug.log 
/usr/bin/php -f /var/www/infoskidka.ru/www/cli.php test sape sdf
Link: http://www.infoskidka.ru/common/php_debug.txt

Test script:
---
I can't create test script beacuse if I delete some lines in script, error have 
disappear. 







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

Req #63255 [Opn->Csd]: 404 page looks amateur

2013-10-24 Thread yohgaki

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

 ID: 63255
 Updated by: yohg...@php.net
 Reported by:pascal dot chevrel at free dot fr
 Summary:404 page looks amateur
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:Built-in web server
 Operating System:   all
 PHP Version:master-Git-2012-10-10 (Git)
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 New Comment:

It seems fixed already.


Previous Comments:

[2012-11-09 12:36:15] pascal dot chevrel at free dot fr

Can somebody have a look at this simple patch? I saw that 5.4.9RC1 is released 
and I believe it contains my html fix for the 404 page 
(https://bugs.php.net/bug.php?id=63242), it would have been nice to have the 
css part included as well.


[2012-10-10 15:00:15] pascal dot chevrel at free dot fr

Description:

This is a followup to https://bugs.php.net/bug.php?id=63242 where I provided a 
patch to have html5 syntax and simpler html/css to the 404 page

The 404 page uses styles that were copy/pasted from a 2002 commit for phpinfo 
styling. It looks amateurish, title and text are not aligned, the blue 
background sticks to the title text and it depends partly on the browser 
default html rules, which means that there are differences in display across 
browsers for that page.

I propose a slight change of the css used that will result in something a bit 
leaner while keeping the same blue colour that represents PHP, here is a 
before/after screenshot:
http://chevrel.org/images/phpbugs/bug63242v2_compare.png

This is a simple patch that passes all tests, I will attach it here later today.







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

Bug #63419 [Fbk]: PDO::quote for SQLite truncates strings on \0

2013-10-24 Thread yohgaki

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

 ID: 63419
 Updated by: yohg...@php.net
 Reported by:daniel dot kinzler at wikimedia dot de
 Summary:PDO::quote for SQLite truncates strings on \0
 Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

FYI

quoting is done by PHP, not SQLite, since there is no such API in SQLite3.


Previous Comments:

[2013-10-24 07:28:53] yohg...@php.net

I'm not sure if this change is usable or not.

SQLite3 does not have quote feature. It only has prepared query type API. Even 
if I change quote method, it may not work.

Are you sure quote works with null byte escapes? If I were sqlite3 developer, I 
just don't care escaped chars, etc, in a SQL string since there should not be 
such chars in SQL query definition strings.

If you find out it works, this behavior may be fixed.


[2012-11-02 11:30:47] daniel dot kinzler at wikimedia dot de

I'd like to add some information about my use case for this. I was storing 
serialized PHP objects in the database. Serialized PHP objects seem to use NUL 
(\0) to mark protected and private fields. Trying to store such a string into 
SQLite would truncate it, effectively rendering the serialized data unusable.

Now, why the hell does PHP use \0 in the serialized representation of objects?! 
Serializations should be robust and designed with interoperability in mind! Oh 
well, I guess that's a rant for another time.


[2012-11-02 11:16:39] daniel dot kinzler at wikimedia dot de

Sorry, here's the correct version of the test script:

 false ) );
$result = $pdo->quote( $data );


print "Raw: " . $result . "\n";
print "Hex: " . bin2hex( $result ) . "\n";


[2012-11-02 11:06:17] daniel dot kinzler at wikimedia dot de

Description:

PDO::quote for SQLite is not binary safe, it silently truncates strings on \0. 
Either, \0 should be supported, or the method should trigger a warning if \0 is 
found and return false.

Note that the same problem exists with SQLite3::escapeString, see Bug 62361. In 
that report, someone pointed to SQLite's mprintf as the culprit 
. From mprintf's documentation:

"The %q option works like %s in that it substitutes a nul-terminated string 
from the argument list."

It operates on null-terminated strings, so null must not be present in strings. 
PDO needs to work around this fact.

Test script:
---
 false ) );
print "PDO/SQLite: " . bin2hex( $pdo->quote( $data ) ) . "\n";


Expected result:

Raw: 'xy'
Hex: 2778007827

Note that the 'xy' above is intended to contain an invisible null character.
Alternatively, the hex representation could be used:

Raw: x'2778007827'.

That would probably be the safest option, and should Just Work with existing 
code.


Actual result:
--
Raw: 'x'
Hex: 277827







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

Bug #63419 [Opn->Fbk]: PDO::quote for SQLite truncates strings on \0

2013-10-24 Thread yohgaki

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

 ID: 63419
 Updated by: yohg...@php.net
 Reported by:daniel dot kinzler at wikimedia dot de
 Summary:PDO::quote for SQLite truncates strings on \0
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10
 PHP Version:5.3.18
 Block user comment: N
 Private report: N

 New Comment:

I'm not sure if this change is usable or not.

SQLite3 does not have quote feature. It only has prepared query type API. Even 
if I change quote method, it may not work.

Are you sure quote works with null byte escapes? If I were sqlite3 developer, I 
just don't care escaped chars, etc, in a SQL string since there should not be 
such chars in SQL query definition strings.

If you find out it works, this behavior may be fixed.


Previous Comments:

[2012-11-02 11:30:47] daniel dot kinzler at wikimedia dot de

I'd like to add some information about my use case for this. I was storing 
serialized PHP objects in the database. Serialized PHP objects seem to use NUL 
(\0) to mark protected and private fields. Trying to store such a string into 
SQLite would truncate it, effectively rendering the serialized data unusable.

Now, why the hell does PHP use \0 in the serialized representation of objects?! 
Serializations should be robust and designed with interoperability in mind! Oh 
well, I guess that's a rant for another time.


[2012-11-02 11:16:39] daniel dot kinzler at wikimedia dot de

Sorry, here's the correct version of the test script:

 false ) );
$result = $pdo->quote( $data );


print "Raw: " . $result . "\n";
print "Hex: " . bin2hex( $result ) . "\n";


[2012-11-02 11:06:17] daniel dot kinzler at wikimedia dot de

Description:

PDO::quote for SQLite is not binary safe, it silently truncates strings on \0. 
Either, \0 should be supported, or the method should trigger a warning if \0 is 
found and return false.

Note that the same problem exists with SQLite3::escapeString, see Bug 62361. In 
that report, someone pointed to SQLite's mprintf as the culprit 
. From mprintf's documentation:

"The %q option works like %s in that it substitutes a nul-terminated string 
from the argument list."

It operates on null-terminated strings, so null must not be present in strings. 
PDO needs to work around this fact.

Test script:
---
 false ) );
print "PDO/SQLite: " . bin2hex( $pdo->quote( $data ) ) . "\n";


Expected result:

Raw: 'xy'
Hex: 2778007827

Note that the 'xy' above is intended to contain an invisible null character.
Alternatively, the hex representation could be used:

Raw: x'2778007827'.

That would probably be the safest option, and should Just Work with existing 
code.


Actual result:
--
Raw: 'x'
Hex: 277827







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

Bug #65550 [Com]: get_browser() incorrectly parsers entries with "+" sign.

Bug #63355 [Opn->Fbk]: PHP 5.3.x failes with core dump

Bug #63510 [Asn->Opn]: Integer overflow with chr

Bug #65905 [Com]: [16-Oct-2013 01:19:12 Europe/Vienna] PHP Warning: Unknown: No such file or dir

Bug #65955 [Csd]: Invalid Json response

Req #27205 [Opn->Csd]: fnmatch support for windows

Bug #49874 [Opn]: ftell() and fseek() inconsistency when using stream filters

[PHP-BUG] Bug #65947 [NEW]: basename is no more working after fgetcsv in certain situation

[PHP-BUG] Bug #65955 [NEW]: Invalid Json response

Req #45927 [Opn->Csd]: man page spelling errors, misused minus signs, and bad whatis entriewds

Bug #51846 [Opn->Csd]: SimpleXMLElement iterator produces unexpected results

Bug #54612 [Opn->Fbk]: random Error 404

[PHP-BUG] Bug #65945 [NEW]: Nested use of pdo->prepare()->execute clears the outer resultset-object

Bug #52598 [Opn->Csd]: zend_mm_heap corrupted

Req #63255 [Opn->Csd]: 404 page looks amateur

Bug #63419 [Fbk]: PDO::quote for SQLite truncates strings on \0

Bug #63419 [Opn->Fbk]: PDO::quote for SQLite truncates strings on \0

17 matches

Site Navigation

Mail list logo

Footer information