Bug #45357 [NoF-Dup]: sybase-ct fails against sybase-15_0 on 64-bit centos 5
Edit report at http://bugs.php.net/bug.php?id=45357edit=1 ID: 45357 Updated by: the...@php.net Reported by:temmel at jcvi dot org Summary:sybase-ct fails against sybase-15_0 on 64-bit centos 5 -Status: No Feedback +Status: Duplicate Type: Bug Package:Sybase-ct (ctlib) related Operating System: Centos 5 x86_64 PHP Version:5.2.9 Assigned To:thekid Block user comment: N New Comment: This one looks like a duplicate of bug #50827 to me, which I fixed by a similar patch and committed that to SVN (trunk, 5_3, 5_2). So compiling PHP with sybase_ct w/ 64-bit libraries should work just fine by now. If not, can you provide a patch against current SVN? Previous Comments: [2010-08-20 22:39:20] royanee at yahoo dot com Updated the patch again after debugging an issue where the severity level was either very large number or 116. It needed the -DSYB_LP64 CFLAG and now is able to correctly parse server communications, severity levels and query results. Tested successfully on RHEL 5 x86_64, using PHP 5.3.2. [2010-08-20 19:57:08] royanee at yahoo dot com After these steps: cd ext/sybase_ct; patch -p2 sybase-configm4.diff; phpize; ./configure; Output: checking for Sybase-CT support... yes, shared ./configure: line 21483: syntax error: unexpected end of file However, if I replace else if with elif and switch the test -f from $SYBASE_CT_INCDIR/libsybct64 to $SYBASE_CT_LIBDIR/libsybct64.so, it compile successfully. I'll try attaching my updated patch. [2009-05-25 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-05-17 20:53:24] j...@php.net How did you test? Did you regenerate configure before running it again? [2009-04-27 17:59:33] temmel at jcvi dot org No, the patch did not fix the problem. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=45357 -- Edit this bug report at http://bugs.php.net/bug.php?id=45357edit=1
[PHP-BUG] Bug #52666 [NEW]: file_get_contents function can not set the HTTP headers
From:
Operating system: Fedora 13
PHP version: 5.2.14
Package: Filesystem function related
Bug Type: Bug
Bug description:file_get_contents function can not set the HTTP headers
Description:
My PHP is 5.2.13,if use under code
?php
// Create a stream
$opts = array(
'http'=array(
'method'=GET,
'header'=Accept-language: en\r\n .
Cookie: foo=bar\r\n
)
);
$context = stream_context_create($opts);
// Open the file using the HTTP headers set above
$file = file_get_contents('http://www.example.com/', false, $context);
?
use Wireshark check HTTP request header is:
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept: */*\r\n
I set header not exists
Test script:
---
?php
// Create a stream
$opts = array(
'http'=array(
'method'=GET,
'header'=Accept-language: en\r\n .
Cookie: foo=bar\r\n
)
);
Expected result:
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept-language: en\r\n
Cookie: foo=bar\r\n
Actual result:
--
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept: */*\r\n
--
Edit bug report at http://bugs.php.net/bug.php?id=52666edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52666r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52666r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52666r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52666r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52666r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52666r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52666r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52666r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52666r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52666r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52666r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52666r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52666r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52666r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52666r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52666r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52666r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52666r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52666r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52666r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52666r=mysqlcfg
Req #52655 [Csd-ReO]: SimpleXMLIterator supports ArrayAccess without implementing Interface
Edit report at http://bugs.php.net/bug.php?id=52655edit=1 ID: 52655 Updated by: ka...@php.net Reported by:ircmaxell at yahoo dot com Summary:SimpleXMLIterator supports ArrayAccess without implementing Interface -Status: Closed +Status: Re-Opened Type: Feature/Change Request Package:SimpleXML related Operating System: CentOS 5.5 PHP Version:5.3.3 Assigned To:salathe Block user comment: N New Comment: As written on php-doc-cvs@, its as of 5.3.4, not trunk :) Previous Comments: [2010-08-21 21:56:14] sala...@php.net Updated SimpleXMLElement/SimpleXMLIterator interfaces list and added a changelog to SimpleXMLElement synopsis page. [2010-08-21 21:52:42] sala...@php.net Automatic comment from SVN on behalf of salathe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302623 Log: simplexmlelement/iterator implements arrayaccess (doc #52655) [2010-08-21 18:23:57] ka...@php.net Peter, I have fixed the bug in the source and it will be available as of 5.3.4, if you want to take this documentation issue :) [2010-08-21 18:22:48] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302614 Log: Fixed bug #52655 (SimpleXMLIterator supports ArrayAccess without implementing the interface) [2010-08-20 15:58:15] sala...@php.net Moved to Feature Request category. Could you open a separate bug regarding the documentation of this array-style access? Thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52655 -- Edit this bug report at http://bugs.php.net/bug.php?id=52655edit=1
Req #52655 [ReO]: SimpleXMLIterator supports ArrayAccess without implementing Interface
Edit report at http://bugs.php.net/bug.php?id=52655edit=1 ID: 52655 Updated by: ka...@php.net Reported by:ircmaxell at yahoo dot com Summary:SimpleXMLIterator supports ArrayAccess without implementing Interface Status: Re-Opened Type: Feature/Change Request Package:SimpleXML related Operating System: CentOS 5.5 PHP Version:5.3.3 Assigned To:salathe Block user comment: N New Comment: As written on php-doc-cvs@, its as of 5.3.4, not trunk :) Previous Comments: [2010-08-22 13:39:22] ka...@php.net As written on php-doc-cvs@, its as of 5.3.4, not trunk :) [2010-08-21 21:56:14] sala...@php.net Updated SimpleXMLElement/SimpleXMLIterator interfaces list and added a changelog to SimpleXMLElement synopsis page. [2010-08-21 21:52:42] sala...@php.net Automatic comment from SVN on behalf of salathe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302623 Log: simplexmlelement/iterator implements arrayaccess (doc #52655) [2010-08-21 18:23:57] ka...@php.net Peter, I have fixed the bug in the source and it will be available as of 5.3.4, if you want to take this documentation issue :) [2010-08-21 18:22:48] ka...@php.net Automatic comment from SVN on behalf of kalle Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302614 Log: Fixed bug #52655 (SimpleXMLIterator supports ArrayAccess without implementing the interface) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52655 -- Edit this bug report at http://bugs.php.net/bug.php?id=52655edit=1
Req #52655 [ReO-Csd]: SimpleXMLIterator supports ArrayAccess without implementing Interface
Edit report at http://bugs.php.net/bug.php?id=52655edit=1 ID: 52655 Updated by: sala...@php.net Reported by:ircmaxell at yahoo dot com Summary:SimpleXMLIterator supports ArrayAccess without implementing Interface -Status: Re-Opened +Status: Closed Type: Feature/Change Request Package:SimpleXML related Operating System: CentOS 5.5 PHP Version:5.3.3 Assigned To:salathe Block user comment: N New Comment: We can't document a version number which does not exist. For now, the changelog will say Future. When a release is made which contains this change, the docs can be updated to reflect that. Previous Comments: [2010-08-22 13:39:24] ka...@php.net As written on php-doc-cvs@, its as of 5.3.4, not trunk :) [2010-08-22 13:39:22] ka...@php.net As written on php-doc-cvs@, its as of 5.3.4, not trunk :) [2010-08-21 21:56:14] sala...@php.net Updated SimpleXMLElement/SimpleXMLIterator interfaces list and added a changelog to SimpleXMLElement synopsis page. [2010-08-21 21:52:42] sala...@php.net Automatic comment from SVN on behalf of salathe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=302623 Log: simplexmlelement/iterator implements arrayaccess (doc #52655) [2010-08-21 18:23:57] ka...@php.net Peter, I have fixed the bug in the source and it will be available as of 5.3.4, if you want to take this documentation issue :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52655 -- Edit this bug report at http://bugs.php.net/bug.php?id=52655edit=1
[PHP-BUG] Bug #52667 [NEW]: memory_limit ignored
From: Operating system: os x leopard PHP version: 5.2.14 Package: PHP options/info functions Bug Type: Bug Bug description:memory_limit ignored Description: php.ini: memory_limit = 20 ; 20 Bytes not: Maximum amount of memory a script may consume (128MB) phpinfo: memory_limit20 20 seems clear to me at least that any web app on this server should crash, or send error, but it does not: ie like: Bug #52549: No 'M' in memory_limit variable returns 'Could not startup.' but app runs fine! memory-limit is always enabled (--enable-memory-limit removed) default value if memory-limit is set to 128M http://bugs.php.net/42525 -- Edit bug report at http://bugs.php.net/bug.php?id=52667edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52667r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52667r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52667r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52667r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52667r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52667r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52667r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52667r=needscript Try newer version: http://bugs.php.net/fix.php?id=52667r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52667r=support Expected behavior: http://bugs.php.net/fix.php?id=52667r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52667r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52667r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52667r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52667r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52667r=dst IIS Stability: http://bugs.php.net/fix.php?id=52667r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52667r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52667r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52667r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52667r=mysqlcfg
Bug #52667 [Opn]: memory_limit ignored
Edit report at http://bugs.php.net/bug.php?id=52667edit=1 ID: 52667 Updated by: ka...@php.net Reported by:j dot chetwynd at btinternet dot com Summary:memory_limit ignored Status: Open Type: Bug Package:PHP options/info functions Operating System: os x leopard PHP Version:5.2.14 Block user comment: N New Comment: Im not sure I totally understand your issue. So you are saying, that if you set memory_limit to 20 (20 bytes) then you do not get any startup error? Previous Comments: [2010-08-22 15:41:03] j dot chetwynd at btinternet dot com Description: php.ini: memory_limit = 20 ; 20 Bytes not: Maximum amount of memory a script may consume (128MB) phpinfo: memory_limit20 20 seems clear to me at least that any web app on this server should crash, or send error, but it does not: ie like: Bug #52549: No 'M' in memory_limit variable returns 'Could not startup.' but app runs fine! memory-limit is always enabled (--enable-memory-limit removed) default value if memory-limit is set to 128M http://bugs.php.net/42525 -- Edit this bug report at http://bugs.php.net/bug.php?id=52667edit=1
Bug #52667 [Opn-Fbk]: memory_limit ignored
Edit report at http://bugs.php.net/bug.php?id=52667edit=1 ID: 52667 Updated by: ka...@php.net Reported by:j dot chetwynd at btinternet dot com Summary:memory_limit ignored -Status: Open +Status: Feedback Type: Bug Package:PHP options/info functions Operating System: os x leopard PHP Version:5.2.14 Block user comment: N Previous Comments: [2010-08-22 16:23:12] ka...@php.net Im not sure I totally understand your issue. So you are saying, that if you set memory_limit to 20 (20 bytes) then you do not get any startup error? [2010-08-22 15:41:03] j dot chetwynd at btinternet dot com Description: php.ini: memory_limit = 20 ; 20 Bytes not: Maximum amount of memory a script may consume (128MB) phpinfo: memory_limit20 20 seems clear to me at least that any web app on this server should crash, or send error, but it does not: ie like: Bug #52549: No 'M' in memory_limit variable returns 'Could not startup.' but app runs fine! memory-limit is always enabled (--enable-memory-limit removed) default value if memory-limit is set to 128M http://bugs.php.net/42525 -- Edit this bug report at http://bugs.php.net/bug.php?id=52667edit=1
[PHP-BUG] Bug #52668 [NEW]: Iterating over a dateperiod twice is broken
From:
Operating system:
PHP version: 5.3.3
Package: Date/time related
Bug Type: Bug
Bug description:Iterating over a dateperiod twice is broken
Description:
Iterating over a dateperiod twice does not reset the iterator,
but starts the second iteration at the endate.
This is kindof an duplicate of #46874, but Derick asked me to add it
anyways.
Test script:
---
?php
$start= new DateTime('20101212');
$interval = DateInterval::createFromDateString('next day');
$dp = new DatePeriod($start, $interval, 0);
foreach($dp as $dt) {
echo $dt-format('r') . \n; // Sun, 12 Dec 2010 00:00:00 +0100
}
foreach($dp as $dt) {
echo $dt-format('r') . \n; // Mon, 13 Dec 2010 00:00:00 +0100
}
Expected result:
Sun, 12 Dec 2010 00:00:00 +0100
Sun, 12 Dec 2010 00:00:00 +0100
Actual result:
--
Sun, 12 Dec 2010 00:00:00 +0100
Mon, 13 Dec 2010 00:00:00 +0100
--
Edit bug report at http://bugs.php.net/bug.php?id=52668edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52668r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52668r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52668r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52668r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52668r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52668r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52668r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52668r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52668r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52668r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52668r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52668r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52668r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52668r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52668r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52668r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52668r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52668r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52668r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52668r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52668r=mysqlcfg
Bug #52667 [Com]: memory_limit ignored
Edit report at http://bugs.php.net/bug.php?id=52667edit=1 ID: 52667 Comment by: j dot chetwynd at btinternet dot com Reported by:j dot chetwynd at btinternet dot com Summary:memory_limit ignored Status: Feedback Type: Bug Package:PHP options/info functions Operating System: os x leopard PHP Version:5.2.14 Block user comment: N New Comment: sorry, I could not find a way to login, comment or close this bug. has been resolved since updating to 5.3 Previous Comments: [2010-08-22 16:23:12] ka...@php.net Im not sure I totally understand your issue. So you are saying, that if you set memory_limit to 20 (20 bytes) then you do not get any startup error? [2010-08-22 15:41:03] j dot chetwynd at btinternet dot com Description: php.ini: memory_limit = 20 ; 20 Bytes not: Maximum amount of memory a script may consume (128MB) phpinfo: memory_limit20 20 seems clear to me at least that any web app on this server should crash, or send error, but it does not: ie like: Bug #52549: No 'M' in memory_limit variable returns 'Could not startup.' but app runs fine! memory-limit is always enabled (--enable-memory-limit removed) default value if memory-limit is set to 128M http://bugs.php.net/42525 -- Edit this bug report at http://bugs.php.net/bug.php?id=52667edit=1
[PHP-BUG] Bug #52669 [NEW]: Bug Reporter bug
From: Operating system: not relevant PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:Bug Reporter bug Description: when originally filing bug #52667, my browser asked me if I wished to save the email and password used. I saved them, thinking this would log me back in. but when I returned to comment and close bug I have pink banner on bug page: ERROR: ⢠Authentication failed: Incorrect username please advise how to re-authenticate and login? -- Edit bug report at http://bugs.php.net/bug.php?id=52669edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52669r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52669r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52669r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52669r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52669r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52669r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52669r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52669r=needscript Try newer version: http://bugs.php.net/fix.php?id=52669r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52669r=support Expected behavior: http://bugs.php.net/fix.php?id=52669r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52669r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52669r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52669r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52669r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52669r=dst IIS Stability: http://bugs.php.net/fix.php?id=52669r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52669r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52669r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52669r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52669r=mysqlcfg
Bug #52667 [Fbk-Wfx]: memory_limit ignored
Edit report at http://bugs.php.net/bug.php?id=52667edit=1 ID: 52667 Updated by: ka...@php.net Reported by:j dot chetwynd at btinternet dot com Summary:memory_limit ignored -Status: Feedback +Status: Wont fix Type: Bug Package:PHP options/info functions Operating System: os x leopard PHP Version:5.2.14 Block user comment: N New Comment: Thanks, 5.2 only gets security updates so this is a Wont fix :) Previous Comments: [2010-08-22 16:53:18] j dot chetwynd at btinternet dot com sorry, I could not find a way to login, comment or close this bug. has been resolved since updating to 5.3 [2010-08-22 16:23:12] ka...@php.net Im not sure I totally understand your issue. So you are saying, that if you set memory_limit to 20 (20 bytes) then you do not get any startup error? [2010-08-22 15:41:03] j dot chetwynd at btinternet dot com Description: php.ini: memory_limit = 20 ; 20 Bytes not: Maximum amount of memory a script may consume (128MB) phpinfo: memory_limit20 20 seems clear to me at least that any web app on this server should crash, or send error, but it does not: ie like: Bug #52549: No 'M' in memory_limit variable returns 'Could not startup.' but app runs fine! memory-limit is always enabled (--enable-memory-limit removed) default value if memory-limit is set to 128M http://bugs.php.net/42525 -- Edit this bug report at http://bugs.php.net/bug.php?id=52667edit=1
[PHP-BUG] Bug #52671 [NEW]: PHP gettext not uniformying CRLF newlines
From: Operating system: Win32 PHP version: 5.2.14 Package: Gettext related Bug Type: Bug Bug description:PHP gettext not uniformying CRLF newlines Description: I already started a dicussion about that on bug-gnu-gett...@gnu.org but it turned out that it may be a PHP gettext implementation issue. It's a problem I encounter while using the PHP gettext functions on PHP files with CRLF newlines (Windows format). See the test script below and its comment for an explanation. The problem is that xgettext, from GNU, following the recommandations of the Unicode consortium ( http://www.unicode.org/reports/tr13/tr13-9.html ), changes every CRLF for simple LF when extracting strings from the PHP file. So if a PHP file contains CRLF newlines, xgettext will turn them into LF when writing the catalog. But PHP gettext functions will still look for CRLF newlines in the catalog when finding a string with CRLF newline. The matching msgid won't be found then. In short, parsing a Windows PHP file with xgettext, and then running PHP gettext on this file will not work, the translation will not be found, because the comparison between strings will fail. Test script: --- ?php // If this text is saved in a Unix-style newlines format (LF) // it will work. In Windows-style (CRLF), it won't, because the // linebreak in the string will be encoded as CRLF, so it won't // be found in the catalog, which universally encode newlines as LF. $s = gettext( Hello! My name is Foo Bar. ); Expected result: Regardless of the newline encoding of the file, the above string should be found in the catalog's msgids, which always use the LF newline. Actual result: -- For the moment, on Windows-style files, strings with a linebreak inside are not translated even though their translation is available in the catalog. -- Edit bug report at http://bugs.php.net/bug.php?id=52671edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52671r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52671r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52671r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52671r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52671r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52671r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52671r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52671r=needscript Try newer version: http://bugs.php.net/fix.php?id=52671r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52671r=support Expected behavior: http://bugs.php.net/fix.php?id=52671r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52671r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52671r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52671r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52671r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52671r=dst IIS Stability: http://bugs.php.net/fix.php?id=52671r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52671r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52671r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52671r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52671r=mysqlcfg
Bug #52658 [Opn]: odbc_fetch_row doesn't fetch memo field
Edit report at http://bugs.php.net/bug.php?id=52658edit=1
ID: 52658
User updated by:cyoung at gcs dot neric dot org
Reported by:cyoung at gcs dot neric dot org
Summary:odbc_fetch_row doesn't fetch memo field
Status: Open
Type: Bug
Package:ODBC related
Operating System: Windows Sever 2008
PHP Version:5.3.3
Block user comment: N
New Comment:
I was able to find a way to fix this problem I was having when using
odbc_fetch_row with memo fields. When I connected to the database I
used the optional cursor_type parameter.
$cnx = odbc_connect('$databaseName', 'user', 'pass', SQL_CUR_USE_ODBC);
This seemed to allow odbc_fetch_row to retrieve the memo field
successfully. I was getting the error below before inserting the cursor
type into odbc_connect.
PHP Warning: odbc_result() [a
href='function.odbc-result'function.odbc-result/a]: SQL error:
[Microsoft][ODBC Microsoft Access Driver]Invalid cursor position; no
keyset defined , SQL state S1109 in SQLGetData
Previous Comments:
[2010-08-20 17:38:42] cyoung at gcs dot neric dot org
Description:
odbc_fetch_row doesn't retrieve a memo field from MS access db. It does
however retrieve all the other fields in the same row successfully.
Without the use of odbc_fetch_row, odbc_result retrieves the memo field
exactly as expected. This obviously poses a problem only when trying to
retrieve more than one row in a database, which is usually the case more
than not.
Test script:
---
while(odbc_fetch_row($result)) {
$newsID = odbc_result($result, newsID);
$newsTitle = odbc_result($result, newsTitle);
$titleLink = odbc_result($result, titleLink);
$brief = trim(odbc_result($result, brief));
$link = $titleLink.$newsID;
$newsBrief = substr($brief, 0, 75);
echo div id=\newsLink\ class=\newsTitle\a href=\$link\
onclick=\window.open('$link', 'GCSNews', 'width=500, height=400,
menubar=no, toolbar=no, resizable=no, top=100, left=200'); return
false;\$newsTitle/a/div;
echo div class=\newsBrief\$newsBrief.../div;
}
Expected result:
I expected the memo field brief to be fetched, trimmed, and then a
substring of the first 75 characters to be stored in $newBrief and print
out followed by ...
Actual result:
--
...
when trouble shooting, just echoing $brief showed nothing in the
browser. $brief is an empty string when used in conjunction with
odbc_fetch_row.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52658edit=1
Bug #46723 [Opn-Asn]: FastCGI is incredibly slow due to TCP ack delay
Edit report at http://bugs.php.net/bug.php?id=46723edit=1 ID: 46723 Updated by: fel...@php.net Reported by:jost_boekemeier at users dot sf dot net Summary:FastCGI is incredibly slow due to TCP ack delay -Status: Open +Status: Assigned Type: Bug Package:CGI related Operating System: * PHP Version:5CVS, 6CVS (2008-12-08) -Assigned To: +Assigned To:dmitry Block user comment: N Previous Comments: [2010-03-20 18:41:35] jost_boekemeier at users dot sf dot net Please excuse the delay. I didn't noticed that you were asking for a patch. After applying the patch fastcgi renders 900 pages in 1m8.095s, compared to 1m40.428s before. [notice for me] $ time for i in `seq 900`; do wget -O/dev/null -o/dev/null http://localhost:8080/JavaBridge/sessionSharing.php; done real1m40.428s user0m1.587s sys 0m3.108s $ time for i in `seq 900`; do wget -O/dev/null -o/dev/null http://localhost:8080/JavaBridgeO/sessionSharing.php; done real1m8.095s user0m1.212s sys 0m2.485s [2009-01-29 01:00:16] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-01-21 19:27:40] j...@php.net Patches are always welcome, you don't need to wait for a request..:) [2008-11-30 17:42:32] jost_boekemeier at users dot sf dot net Description: The PHP side of a socket-based FastCGI communication is unbuffered since PHP 5.1.4 (maybe earlier). write/write/read cycles have a huge performance impact, on the latest Linux kernel the FastCGI SAPI is actually slower than executing a CGI for each request! The actual problem is caused by the two unbuffered write() operations, which run into a delayed ack and therefore cause a latency of 4us on FC10 and 500ms(!) on FreeBSD. As an immediate fix I suggest to switch on NDELAY for the PHP FastCGI socket communication. I can provide a patch if you want me to. Regards, Jost Bökemeier Reproduce code: --- - Expected result: - Actual result: -- - -- Edit this bug report at http://bugs.php.net/bug.php?id=46723edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410edit=1 ID: 50410 Comment by: michaelhood at gmail dot com Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Assigned Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:5.2.11 Assigned To:pajoye Block user comment: N New Comment: Still exists with the php_curl.dll bundled with 5.3.3. Previous Comments: [2010-05-25 02:26:08] andrew at mammoth dot com dot au Hi, Windows Explorer says the version of libeay32.dll for me which was included with PHP is 0.9.8k I downloaded the sources from www.openssl.org/sources for that version and the latest 1.0.0. I've pastebin'd the rand_win.c code which has the RAND_screen() method mentioned earlier. OpenSSL 0.9.8k: http://pastebin.com/CjCt7bL3 OpenSSL 1.0.0: http://pastebin.com/yeQS1khQ Diff: http://pastebin.com/fWuyTKDC It's interesting to see the usage of MAXDELAY (1 second) and several methods within that loop referencing that delay (when added together, maybe add up to the 3-5 seconds delay people are experiencing). Even the latest OpenSSL code appears to have this problem? I've only skimmed over the diff ^ changes, perhaps they have improved/reduced the delay for Windows I'm not sure. Probably worth testing a newer libeay32.dll/php_curl module though. If you need me to test I'd be happy to, just link me to the updated files. [2010-05-25 02:05:55] andrew at mammoth dot com dot au Confirmed as still a problem in 5.2.13 I copied my php.ini file from c:\php\php.ini to \php\523\php.ini and updated the extension_dir directory inside the file to point to the new \php\523\ext folder. I verified this change worked by running: php -c . -v This prints: PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies And a delay of 5 seconds. If I rename the 523\ext\php_curl.dll and re-run the command, I get an error about a missing module as expected (verified this ext dir is being used etc). If I uncomment php_curl.dll under extensions in php.ini, the same command completes immediately. On my system at least, disabling the php_curl extension fixes the problem. Interestingly, I do not have any page load delay using curl on web pages (uisng php 5.2.11). I am using IIS with Windows 7. The example code from the php documentation page works as expected: ?php $ch = curl_init(http://www.example.com/;); $fp = fopen(example_homepage.txt, w); curl_setopt($ch, CURLOPT_FILE, $fp); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); curl_close($ch); fclose($fp); --- (I see an example_homepage.txt file with the html contents inside). phpinfo() also reports the CURL extension has loaded. Commenting out the php_curl extension in the ini file and restarting IIS (to refresh the php ini file) shows the expected 'Fatal error: Call to undefined function curl_init()' error. So to summarise: 1) The latest PHP version still appears to have this problem 2) The md5sum of php_curl.dll between these php versions has changed; however the included libeay32.dll file has remained the same 3) It's interesting that CURL (and even just loading a blank PHP page) runs without delay under IIS, but using the CLI causes a problem. 4) mailnew2ster at mail dot ru's comment about libeay32.dll being patched is interesting. Perhaps this is the fault of OpenSSL under Windows? Maybe libeay32.dll needs to be updated to a newer version in the PHP distribution? I found another version of this file on my computer, but using that in place of the one PHP comes with causes an 'Ordinal not found' error during PHP startup when it tries to load the curl extension. I suspect PHP/php_curl needs to be compiled/linked to the newer DLL for it to work, so I cannot test a newer libeay32.dll build on my own. It may be worth a shot finding a newer version of this library (from OpenSSL?) and compiling/linking the php_curl module against it and then testing if the extension still causes the delay with an updated libeay32.dll. [2010-05-25 01:29:40] paj...@php.net can you try with 5.2.13 pls? But I very much doubt that the 5 seconds are due to the problem described in this report. [2010-05-25 00:56:48] andrew at mammoth dot com dot au This is STILL a problem. Windows 7 64bit here, PHP 5.2.11 php -v takes 5 seconds for the script to terminate Five seconds for *any* CLI operation
[PHP-BUG] Bug #52672 [NEW]: selecting a MySQL database
From:
Operating system: Windows XP
PHP version: 5.2.14
Package: Session related
Bug Type: Bug
Bug description:selecting a MySQL database
Description:
These statements will not return true on the mysql_select_db
Is there something I need to do in MySQL to make sure the database is
selectable.
The connect statement works, the mysql_select_db statement fails.
Test script:
---
//
$link = mysql_connect('localhost','vlf','vlf') or die (connect
problem);
$db = mysql_select_db('vlf',$link) or die (false DB);
Expected result:
select the database from MySQL
Actual result:
--
false db
--
Edit bug report at http://bugs.php.net/bug.php?id=52672edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52672r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52672r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52672r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52672r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52672r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52672r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52672r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52672r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52672r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52672r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52672r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52672r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52672r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52672r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52672r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52672r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52672r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52672r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52672r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52672r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52672r=mysqlcfg
[PHP-BUG] Bug #52673 [NEW]: Freeze if a class namend ArrayList shall be instantiated
From:
Operating system: Windows 7 x64
PHP version: 5.3SVN-2010-08-23 (snap)
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Freeze if a class namend ArrayList shall be instantiated
Description:
I wanted to instantiate a object of the class ArrayList but did not define
a use ...\ArrayList and everything hung up. No response was send from the
server, neither a error message nor an empty page.
Test script:
---
namespace test;
class A{
public function __construct(){
$arr = new ArrayList();
}
}
-
namespace test2;
class ArrayList{...}
-
namespace test3;
$class = new ReflectionClass('A');
$aObj = $class-newInstance(null);
Expected result:
Error, test3\ArrayList was not found
Actual result:
--
Endless loop
--
Edit bug report at http://bugs.php.net/bug.php?id=52673edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52673r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52673r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52673r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52673r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52673r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52673r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52673r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52673r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52673r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52673r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52673r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52673r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52673r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52673r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52673r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52673r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52673r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52673r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52673r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52673r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52673r=mysqlcfg
[PHP-BUG] Bug #52674 [NEW]: [FPM] Status page does not work under Apache 2.2
From: Operating system: Linux Debian PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:[FPM] Status page does not work under Apache 2.2 Description: Apache 2 ends up with an error while trying to get content of /status url. Ping url works fine. Same problem with /status?json and /status?html. Apache version: 2.2.16, mpm-worker mod_fastcgi version: 2.4.6 Test script: --- IfModule mod_fastcgi.c FastCGIExternalServer /php5-fpm-handler -socket /var/run/php5-fpm.sock AddHandler php5-fcgi .php LocationMatch /(ping|status) SetHandler php5-fcgi-virt Action php5-fcgi-virt /php5-fpm-handler.fcgi virtual /LocationMatch Action php5-fcgi /php5-fpm-handler.fcgi ScriptAlias /php5-fpm-handler.fcgi /php5-fpm-handler /IfModule Expected result: FPM status page Actual result: -- 500 Internal error Logged in Apache's error log: [Mon Aug 23 04:16:55 2010] [error] [client 127.0.0.1] FastCGI: comm with server /php5-fpm-handler aborted: error parsing headers: malformed header 'text/plain' -- Edit bug report at http://bugs.php.net/bug.php?id=52674edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52674r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52674r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52674r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52674r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52674r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52674r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52674r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52674r=needscript Try newer version: http://bugs.php.net/fix.php?id=52674r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52674r=support Expected behavior: http://bugs.php.net/fix.php?id=52674r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52674r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52674r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52674r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52674r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52674r=dst IIS Stability: http://bugs.php.net/fix.php?id=52674r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52674r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52674r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52674r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52674r=mysqlcfg
Bug #52672 [Opn-Bgs]: selecting a MySQL database
Edit report at http://bugs.php.net/bug.php?id=52672edit=1
ID: 52672
Updated by: ahar...@php.net
Reported by:ahowe at frii dot com
Summary:selecting a MySQL database
-Status: Open
+Status: Bogus
Type: Bug
Package:Session related
Operating System: Windows XP
PHP Version:5.2.14
Block user comment: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2010-08-23 01:13:16] ahowe at frii dot com
Description:
These statements will not return true on the mysql_select_db
Is there something I need to do in MySQL to make sure the database is
selectable.
The connect statement works, the mysql_select_db statement fails.
Test script:
---
//
$link = mysql_connect('localhost','vlf','vlf') or die (connect
problem);
$db = mysql_select_db('vlf',$link) or die (false DB);
Expected result:
select the database from MySQL
Actual result:
--
false db
--
Edit this bug report at http://bugs.php.net/bug.php?id=52672edit=1
Bug #52666 [Opn-Fbk]: file_get_contents function can not set the HTTP headers
Edit report at http://bugs.php.net/bug.php?id=52666edit=1
ID: 52666
Updated by: ahar...@php.net
Reported by:chopins dot xiao at gmail dot com
Summary:file_get_contents function can not set the HTTP
headers
-Status: Open
+Status: Feedback
Type: Bug
Package:Filesystem function related
Operating System: Fedora 13
PHP Version:5.2.14
Block user comment: N
New Comment:
I can't reproduce this on 5.2.13 or the current 5.2 snapshot under any
configuration I can come up with. Request headers always seem to be sent
as expected.
As 5.2 is closed for bug fixes, can you please see if the bug occurs
with PHP 5.3.3? If it does, please also provide your configure line from
phpinfo().
Previous Comments:
[2010-08-22 13:04:59] chopins dot xiao at gmail dot com
Description:
My PHP is 5.2.13,if use under code
?php
// Create a stream
$opts = array(
'http'=array(
'method'=GET,
'header'=Accept-language: en\r\n .
Cookie: foo=bar\r\n
)
);
$context = stream_context_create($opts);
// Open the file using the HTTP headers set above
$file = file_get_contents('http://www.example.com/', false, $context);
?
use Wireshark check HTTP request header is:
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept: */*\r\n
I set header not exists
Test script:
---
?php
// Create a stream
$opts = array(
'http'=array(
'method'=GET,
'header'=Accept-language: en\r\n .
Cookie: foo=bar\r\n
)
);
Expected result:
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept-language: en\r\n
Cookie: foo=bar\r\n
Actual result:
--
User-Agent: PHP/5.2.13\r\n
Host: en.wikipedia.org\r\n
Accept: */*\r\n
--
Edit this bug report at http://bugs.php.net/bug.php?id=52666edit=1
