Bug #44234 [Com]: call to undefined function mssql_connect()
Edit report at https://bugs.php.net/bug.php?id=44234&edit=1 ID: 44234 Comment by: rubia_mit09 at yahoo dot com Reported by:adamgeoffrey12 at yahoo dot com Summary:call to undefined function mssql_connect() Status: Bogus Type: Bug Package:MSSQL related Operating System: win xp sp2 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: i have a mssql server 2000, and want to connect with php at localhost but the error is"undefined function mssql_connect()" and i have also configure php.ini file but error still remaining kindly tell me solution of that error Previous Comments: [2011-12-07 06:44:59] rubia_mit09 at yahoo dot com i have a problem in connectivity php with mssql the error is "undefined function mssql_connect() " at local host please tell me solution [2008-02-24 19:14:48] msara...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2008-02-24 11:51:13] adamgeoffrey12 at yahoo dot com Description: im using iis,sql server 2005 and php 5.2.5 the php_mssql.dll extension is already uncommented in php.ini of php 5.2.5 win 32 installer, i have put the php_mssql.dll and ntwdblib.dll in system 32 and php\:extension folders the fatal error call to undefined function mssql_connect() still comes. testing for availability of php functions using;- it returns the else part, where the problem will be??plz help me i have suffered this problem for months. Reproduce code: --- the code i used to connect to the database is as follows;- then Expected result: to connect to sql server, unfortunately i couldnt, plz plz help me out of this big problem. -- Edit this bug report at https://bugs.php.net/bug.php?id=44234&edit=1
Req #54514 [Com]: Get php binary path during script execution
Edit report at https://bugs.php.net/bug.php?id=54514&edit=1 ID: 54514 Comment by: patrickalla...@php.net Reported by:frederic dot hardy at mageekbox dot net Summary:Get php binary path during script execution Status: Open Type: Feature/Change Request Package:PHP options/info functions PHP Version:Irrelevant Block user comment: N Private report: N New Comment: PHP does provide a path to the binary directory: PHP_BINDIR However it is true it doesn't contain the executable itself. Previous Comments: [2011-04-12 14:11:00] frederic dot hardy at mageekbox dot net Description: Currently, PHP does not provide any solution to retrieve PHP binary path in userland. There is a workaround with some *NIX shells like bash, which provide $_, available in $_SERVER['_'] in userland. However, it's not a reliable solution (cron task, etc.), and this hack is not available on Windows. So, a constant like PHP_BINARY (similar to PHP_VERSION and other PHP_* constants) seems to be a good solution. -- Edit this bug report at https://bugs.php.net/bug.php?id=54514&edit=1
[PHP-BUG] Bug #60455 [NEW]: stream_get_line reports two lines instead of one
From: Operating system: linux PHP version: Irrelevant Package: Streams related Bug Type: Bug Bug description:stream_get_line reports two lines instead of one Description: If a file consists of single line, and you use a straightforward loop over all lines using stream_get_line, you may be suprised that there are actually two lines, where the second one is empty string. This is inconsistent with the case where you actually have two lines in a file, and stream_get_line reports two lines as expected without the additional empty third line. This inconsistency makes it quite difficult to write a correct code. Test script: --- I have three files: lopuszanski@vanisoft:~$ hexdump -C one_line.txt 61 0a |a.| 0002 lopuszanski@vanisoft:~$ hexdump -C two_lines.txt 61 0a 62 0a |a.b.| 0004 lopuszanski@vanisoft:~$ hexdump -C two_lines_one_of_which_is_empty.txt 61 0a 0a |a..| 0003 And the following script: lopuszanski@vanisoft:~$ cat test.php Expected result: lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" Actual result: -- lopuszanski@vanisoft:~$ php test.php < one_line.txt string(1) "a" string(0) "" lopuszanski@vanisoft:~$ php test.php < two_lines.txt string(1) "a" string(1) "b" lopuszanski@vanisoft:~$ php test.php < two_lines_one_of_which_is_empty.txt string(1) "a" string(0) "" -- Edit bug report at https://bugs.php.net/bug.php?id=60455&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60455&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60455&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60455&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60455&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60455&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60455&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60455&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60455&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60455&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60455&r=support Expected behavior: https://bugs.php.net/fix.php?id=60455&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60455&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60455&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60455&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60455&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60455&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60455&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60455&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60455&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60455&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60455&r=mysqlcfg
Req #54514 [Opn->Csd]: Get php binary path during script execution
Edit report at https://bugs.php.net/bug.php?id=54514&edit=1 ID: 54514 Updated by: larue...@php.net Reported by:frederic dot hardy at mageekbox dot net Summary:Get php binary path during script execution -Status: Open +Status: Closed Type: Feature/Change Request Package:PHP options/info functions PHP Version:Irrelevant -Assigned To: +Assigned To:laruence Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. implement in 5.4, thanks Previous Comments: [2011-12-07 10:32:56] larue...@php.net Automatic comment from SVN on behalf of laruence Revision: http://svn.php.net/viewvc/?view=revision&revision=320567 Log: Implemented FR #54514 (Get php binary path during script execution). [2011-12-07 08:57:46] patrickalla...@php.net PHP does provide a path to the binary directory: PHP_BINDIR However it is true it doesn't contain the executable itself. [2011-04-12 14:11:00] frederic dot hardy at mageekbox dot net Description: Currently, PHP does not provide any solution to retrieve PHP binary path in userland. There is a workaround with some *NIX shells like bash, which provide $_, available in $_SERVER['_'] in userland. However, it's not a reliable solution (cron task, etc.), and this hack is not available on Windows. So, a constant like PHP_BINARY (similar to PHP_VERSION and other PHP_* constants) seems to be a good solution. -- Edit this bug report at https://bugs.php.net/bug.php?id=54514&edit=1
[PHP-BUG] Bug #60456 [NEW]: copy() does not work consistently with stream wrappers and safe mode
From:
Operating system: Mac
PHP version: 5.3.8
Package: Safe Mode/open_basedir
Bug Type: Bug
Bug description:copy() does not work consistently with stream wrappers and safe
mode
Description:
Stream wrappers which ultimately result in file operations which should be
permitted by safe mode do not work in some circumstances. For example, a
stream
wrapper which simply stores files in sys_get_temp_dir() works fine without
safe
mode, but fails when that is enabled:
// copy 1: file to stream wrapper
$ok = copy('/tmp/source.txt', 'temp://destination.txt');
// copy 2: stream wrapper to file
$ok = copy('temp://destination.txt', '/tmp/source.txt');
// copy 3: SAME file as stream wrapper to file
$ok = copy(sys_get_temp_dir() . '/destination.txt', '/tmp/source.txt');
Under safe mode, the second copy fails with error message
Warning: copy() [function.copy]: Unable to access temp://destination.txt
in
.../test-copy.php on line ...
This may be related to https://bugs.php.net/bug.php?id=46888
Test script:
---
http://drupal.org/files/test-copy.txt
Expected result:
All three file copies should succeed, since sys_get_temp_dir() returns a
directory
accessible to safe-mode.
Actual result:
--
Second copy fails. Third copy, which refers to the same files, succeeds.
--
Edit bug report at https://bugs.php.net/bug.php?id=60456&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60456&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60456&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60456&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60456&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60456&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60456&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60456&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60456&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60456&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60456&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60456&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60456&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60456&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60456&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60456&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60456&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60456&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60456&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60456&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60456&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60456&r=mysqlcfg
[PHP-BUG] Bug #60457 [NEW]: gc_zval_possible_root SIGSEGV
From:
Operating system: Linux
PHP version: 5.3.8
Package: Scripting Engine problem
Bug Type: Bug
Bug description:gc_zval_possible_root SIGSEGV
Description:
Our application segfaults after completely finishing the request.
Unfortunately I cannot provide a script to reproduce this as it occurs in
an
application consisting of many classes. I have been poking at this with gdb
for a
while, but can't find the cause for this problem.
How can I supply you with the information you need to resolve this? We can
'fix'
the problem by die()-ing in the __destruct of the class that seems to cause
this
Actual result:
--
#0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at
/usr/src/debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x005c0629 in zend_objects_free_object_storage
(object=0x1985580) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x005c46d6 in zend_objects_store_free_object_storage
(objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92
#5 0x00595757 in shutdown_executor () at /usr/src/debug/php-
5.3.8/Zend/zend_execute_API.c:304
#6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php-
5.3.8/Zend/zend.c:891
#7 0x0054f2ce in php_request_shutdown (dummy=) at
/usr/src/debug/php-5.3.8/main/main.c:1640
#8 0x0062b10f in main (argc=3, argv=0x7fffea88) at
/usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at
/usr/src/debug/php-5.3.8/Zend/zend_objects.c:45
45 zend_hash_destroy(object->properties);
(gdb) print *object->ce
$1 = {type = 2 '\002', name = 0xcdce30 "React_Introspection_Controller",
name_length = 30, parent = 0xcb3e78, refcount = 1, constants_updated = 1
'\001',
ce_flags = 0, function_table = {nTableSize = 32,
nTableMask = 31, nNumOfElements = 27, nNextFreeElement = 0,
pInternalPointer
= 0xcde7b0, pListHead = 0xcde7b0, pListTail = 0xce9d10, arBuckets =
0xce8fa8,
pDestructor = 0x599450 ,
persistent = 0 '\000', nApplyCount = 0 '\000', bApplyProtection = 0
'\000'},
default_properties = {nTableSize = 8, nTableMask = 7, nNumOfElements = 5,
nNextFreeElement = 0, pInternalPointer = 0xce74c8,
pListHead = 0xce74c8, pListTail = 0xce7660, arBuckets = 0xcdcf50,
pDestructor = 0x595420 <_zval_ptr_dtor>, persistent = 0 '\000', nApplyCount
= 0
'\000', bApplyProtection = 0 '\000'}, properties_info = {
nTableSize = 8, nTableMask = 7, nNumOfElements = 5, nNextFreeElement =
0,
pInternalPointer = 0xce76c8, pListHead = 0xce76c8, pListTail = 0xce7850,
arBuckets = 0xcde670,
pDestructor = 0x586190 , persistent = 0
'\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'},
default_static_members =
{nTableSize = 8, nTableMask = 7,
nNumOfElements = 0, nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead
= 0x0, pListTail = 0x0, arBuckets = 0xcde6c0, pDestructor = 0x595420
<_zval_ptr_dtor>, persistent = 0 '\000',
nApplyCount = 0 '\000', bApplyProtection = 0 '\000'}, static_members =
0x0,
constants_table = {nTableSize = 8, nTableMask = 7, nNumOfElements = 0,
nNextFreeElement = 0, pInternalPointer = 0x0,
pListHead = 0x0, pListTail = 0x0, arBuckets = 0xcde710, pDestructor =
0x595420 <_zval_ptr_dtor>, persistent = 0 '\000', nApplyCount = 0 '\000',
bApplyProtection = 0 '\000'}, builtin_functions = 0x0,
constructor = 0xca2160, destructor = 0x0, clone = 0x0, __get = 0x0, __set
=
0x0, __unset = 0x0, __isset = 0x0, __call = 0x0, __callstatic = 0x0,
__tostring
= 0x0, serialize_func = 0x0,
unserialize_func = 0x0, iterator_funcs = {funcs = 0x0, zf_new_iterator =
0x0,
zf_valid = 0x0, zf_current = 0x0, zf_key = 0x0, zf_next = 0x0, zf_rewind =
0x0},
create_object = 0, get_iterator = 0,
interface_gets_implemented = 0, get_static_method = 0, serialize = 0,
unserialize = 0, interfaces = 0xcde368, num_interfaces = 1,
filename = 0xcde018 "[...]/Introspection/Controller.php", line_start = 2,
line_end = 82, doc_comment = 0x0,
doc_comment_len = 0, module = 0x0}
--
Edit bug report at https://bugs.php.net/bug.php?id=60457&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60457&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60457&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60457&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60457&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60457&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60457&r=alreadyfixed
Need backtrace:
[PHP-BUG] Bug #60459 [NEW]: phpinfo() don't display symlink ini file path!
From: Operating system: LINUX PHP version: 5.4.0RC2 Package: PHP options/info functions Bug Type: Bug Bug description:phpinfo() don't display symlink ini file path! Description: phpinfo() dipsy ini file path, 5.3 version display true file path, 5.4 version not display... file path: [root@localhost lib]# cd /usr/local/php/lib [root@localhost lib]# ls -al total 904 drwxr-xr-x. 3 root root 4096 Nov 14 23:52 . drwxr-xr-x. 9 root root 4096 Nov 12 10:41 .. lrwxrwxrwx. 1 root root 45 Nov 12 17:07 php.ini -> /home/codebase/server-config/php-api-test.ini Test script: --- Expected result: Loaded Configuration File => /usr/local/php/lib/php.ini Actual result: -- Loaded Configuration File => /home/codebase/server-config/php-api.ini -- Edit bug report at https://bugs.php.net/bug.php?id=60459&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60459&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60459&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60459&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60459&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60459&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60459&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60459&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60459&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60459&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60459&r=support Expected behavior: https://bugs.php.net/fix.php?id=60459&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60459&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60459&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60459&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60459&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60459&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60459&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60459&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60459&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60459&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60459&r=mysqlcfg
Req #50980 [Com]: lambda/anonymous functions do not have proper scope
Edit report at https://bugs.php.net/bug.php?id=50980&edit=1
ID: 50980
Comment by: paulomiguelmarques at gmail dot com
Reported by:nate at frickenate dot com
Summary:lambda/anonymous functions do not have proper scope
Status: Bogus
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.3.1
Block user comment: N
Private report: N
New Comment:
I guess it makes sense to be this way to be consistent with the rest of PHP,
but it should definitely be properly documented on the web site, which it isn't.
Previous Comments:
[2010-11-24 09:45:33] j...@php.net
see the last comments..
[2010-08-28 14:58:49] + at ni-po dot com
function () use (&$country)
will fix it (as the previous comment already says). This is in concordance to
the handling of arguments in normal functions and thus mustn't be changed.
[2010-05-21 00:35:02] a at b dot c dot de
use() parameters are early binding - they use the variable's value at the point
where the lambda function is declared, rather than the point where the lambda
function is called (late binding).
If you want late binding then there is already syntax for that ('&') - which
works as expected to propagate assignments up to the calling scope. To make it
the default would be (a) contrary to the way "ordinary" function parameters are
passed, (b) require the addition of new syntax to indicate that early binding
is wanted, (c) deal with the situation where a used variable doesn't exist at
call time, (d) make it hard to understand the difference between an ordinary
function parameter and a closure.
The problem with allowing variables in the outer scope to leak by default into
the lambda function is that a copy of the ENTIRE collection returned by
get_defined_vars() would need to be persisted for the lifetime of the closure
object (less any that are overridden by call-time arguments) just in case any
of them are needed.
'I imagine this has to do with the php5 "fake references" that are used to pass
objects around.'
The mechanism is the same as that used in Java and C#: the object reference is
passed by value. It's just that in PHP you also have the option of passing the
reference by reference as well (see the chapter in the manual on "Objects and
references", where it explains that what is passed is an "object identifier"
and not a PHP "reference").
[2010-02-09 22:53:17] nate at frickenate dot com
Description:
The way in which variables are passed to the inside of a lambda function via
the 'use (...)' syntax is broken. The entire concept of "scope" or "closures"
does not seem to apply in php whatsoever.
Variables within a lambda are supposed to be resolved/looked up in the parent
scope at runtime when the variable is actually accessed within the lambda
function's code. It seems that php just dumbly creates a copy of the variable
when it sees the definition of the lambda function with the 'use (...)' clause.
Changes to the variable in the parent scope between the moment where the lambda
is defined and the lambda function is called are not propagated.
The worst part happens with objects. When passing in an object instance to a
lambda, any changes to the original object in the parent scope after the lambda
definition do affect the same object (problem 4 in reproduce code), but
replacing the object altogether does not (problem 3 in reproduce code). I
imagine this has to do with the php5 "fake references" that are used to pass
objects around.
I get the feeling this is just a horrible limitation of the devs having hacked
a "best-possible" implementation of "lambdas" into a Zend codebase that can't
handle proper scope lookup. If this is the case, it would be nice if the
documentation could be updated to really nail home the fact that there is no
scoping going on at all, and that quite literally all you get is a copy of the
variable as it exists at the moment the lambda is defined (except for the
strangeness going on with objects).
It's unfortunate that the "solution" for the time being is to *always* pass in
*every* variable as a reference, which results in expected output. But this
requires creating a local copy within the lambda for every variable that one
wants to modify without affecting the parent scope. :'(
Reproduce code:
---
'UnitedStates');
$fn = function () use ($country) { echo $country->name . "\n"; };
$country = (object)array('name' => 'Canada');
$fn();
// problem 4: this outputs "Canada". if this outputs "Canada",
// then so should problem 2 above. otherwise thi
Req #27023 [Opn->Csd]: CURL: CURLOPT_POSTFIELDS does not parse content types for files
Edit report at https://bugs.php.net/bug.php?id=27023&edit=1
ID: 27023
Updated by: pierr...@php.net
Reported by:brianl at stcu dot org
Summary:CURL: CURLOPT_POSTFIELDS does not parse content
types for files
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:cURL related
Operating System: *
PHP Version:*
-Assigned To:
+Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Feature implemented since the bug report.
Previous Comments:
[2005-02-24 03:28:26] jplock at yahoo dot com
I would very much like this functionality to be implemented in PHP5 as I need
it for a project I am currently developing. Thanks.
[2004-03-07 11:54:50] brianl at stcu dot org
Since curl's ability to guess the MIME type of a file by extension is extremely
limited, this represents a very important enhancement for any upload where the
MIME type is used.
[2004-01-25 19:02:13] sni...@php.net
This is not bug but feature request.
Passing just "@/path/to/file.ext" works fine.
The content-type is detected by curl (if it can).
Reclassified.
[2004-01-23 13:26:19] brianl at stcu dot org
Description:
>From the cURL manual:
If you want the contents to be read from a file, use <@filename> as contents.
When specifying a file, you can also specify the file content type by appending
';type=' to the file name.
However, specifing MIME types is not currently supported within PHP.
Reproduce code:
---
$ch= curl_init('http://www.example.com/fupl.php');
curl_setopt($ch,CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,
array('field1'=>'1','field2'=>'2','file'=>'@filepath.ext;type=application/xml'));
$result= curl_exec($ch);
curl_close($ch);
Expected result:
The file should be uploaded with a Content-Type: application/xml header.
Actual result:
--
The entire call fails.
--
Edit this bug report at https://bugs.php.net/bug.php?id=27023&edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: cankoy at ymail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: This, practically, can't be fixed. Mainly because there's no way to know if 'I' is uppercase of 'i' or 'ı' since there's not a separate place for Turkish 'I' in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' or 'İ'). I told 2 years ago and will say it again: PHP should provide a way to turn off case-insensitive function/class name lookup. No good programmer uses this Basic language feature since identifiers are case-sensitive in all real languages like Python, Ruby, C#, Java. Previous Comments: [2011-12-03 22:08:24] sg at facelift-bbt dot com This bug was first reported 9 years ago? This definetly got to be fixed. This is a total stopper. I can reproduce it exactly it is shown below. [2011-11-06 19:29:44] gerd dot katzenbeisser at gmail dot com here is a simple test case using the internal class PharFileInfo Output: Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false [2011-09-16 14:18:21] robin dot bussiek at googlemail dot com @sweiss-at-stylesight thanks for your explanation. Big +1 for any solution to this topic. [2011-09-15 19:59:27] sweiss at stylesight dot com No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. [2011-09-15 19:51:48] robin dot bussiek at googlemail dot com I am sorry to ask this for my understanding: Is it true, that the cause for this bug lies in a false inclusion of the "I" character in the Turkish character set - and therefore results in an unnecessary replacement? If so, my green knowledge leads me to the assumption, that a fix should be rather simple. **duck**, Robin 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=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
[PHP-BUG] Bug #60461 [NEW]: Wrong value outputted
From: Operating system: windows 7 PHP version: 5.4.0RC2 Package: Output Control Bug Type: Bug Bug description:Wrong value outputted Description: --- >From manual page: http://www.php.net/function.floor#refsect1-function.floor- returnvalues --- $diameter = 0.474; //0utput should be 0.5 but floor function rounds the 2 down to 1? $us_ring_size = floor($diameter - 0.458)/0.008) * 0.25; Expected result: 0.5 Actual result: -- 0.25 -- Edit bug report at https://bugs.php.net/bug.php?id=60461&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60461&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60461&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60461&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60461&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60461&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60461&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60461&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60461&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60461&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60461&r=support Expected behavior: https://bugs.php.net/fix.php?id=60461&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60461&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60461&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60461&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60461&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60461&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60461&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60461&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60461&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60461&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60461&r=mysqlcfg
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: gerd dot katzenbeisser at gmail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: This will probably break a lot of existing PHP Code. Why not performing the lookup case-sensitive and if not found fall back to case-insensitive? And if found case- insensitive throw a deprecation warning. Previous Comments: [2011-12-07 18:01:37] cankoy at ymail dot com This, practically, can't be fixed. Mainly because there's no way to know if 'I' is uppercase of 'i' or 'ı' since there's not a separate place for Turkish 'I' in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' or 'İ'). I told 2 years ago and will say it again: PHP should provide a way to turn off case-insensitive function/class name lookup. No good programmer uses this Basic language feature since identifiers are case-sensitive in all real languages like Python, Ruby, C#, Java. [2011-12-03 22:08:24] sg at facelift-bbt dot com This bug was first reported 9 years ago? This definetly got to be fixed. This is a total stopper. I can reproduce it exactly it is shown below. [2011-11-06 19:29:44] gerd dot katzenbeisser at gmail dot com here is a simple test case using the internal class PharFileInfo Output: Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false [2011-09-16 14:18:21] robin dot bussiek at googlemail dot com @sweiss-at-stylesight thanks for your explanation. Big +1 for any solution to this topic. [2011-09-15 19:59:27] sweiss at stylesight dot com No, the problem results because lowercase i (in most languages) and uppercase I (in most languages) are not actually considered to be the upper/lower variant of the same letter in Turkish. In Turkish, the undotted ı is the lowercase of I, and the dotted İ is the uppercase of i. If you have a class named Image, it will break if the locale is changed to turkish because class_exists() function uses zend_str_tolower(), and changes the case on all classes, because they are supposed to be case insensitive. Someone else above explained it very well: class_exists() function uses zend_str_tolower(). zend_str_tolower() uses zend_tolower(). zend_tolower() uses _tolower_l() on Windows and tolower() on other oses. _tolower_l() is not locale aware. tolower() is LC_CTYPE aware. Please, oh please, can someone fix this already? It has been a very long time and it's extremely annoying and difficult to work around if you have a large multilingual website. 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=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at https://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: cankoy at ymail dot com Reported by:spud at nothingness dot org Summary:Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version:5CVS, 4CVS (2005-10-04) Assigned To:dmitry Block user comment: N Private report: N New Comment: > This will probably break a lot of existing PHP Code. Existing code is already broken for those suffering from this problem, don't you get it? I'm not suggesting a permanent turn-off, I'm suggesting a command-line option/a php.ini directive/whatever fits the design of Php engine to implement this as an option. > Why not performing the lookup case-sensitive and if not found fall back to > case-insensitive? And if found case-insensitive throw a deprecation warning. You're suggesting more ceremony, where I suggest optionally skipping a ceremony. Php is an interpreter, performance is important. Previous Comments: [2011-12-07 20:01:07] gerd dot katzenbeisser at gmail dot com This will probably break a lot of existing PHP Code. Why not performing the lookup case-sensitive and if not found fall back to case-insensitive? And if found case- insensitive throw a deprecation warning. [2011-12-07 18:01:37] cankoy at ymail dot com This, practically, can't be fixed. Mainly because there's no way to know if 'I' is uppercase of 'i' or 'ı' since there's not a separate place for Turkish 'I' in code tables. The same holds for 'i' (can't be known if it's lowercase of 'I' or 'İ'). I told 2 years ago and will say it again: PHP should provide a way to turn off case-insensitive function/class name lookup. No good programmer uses this Basic language feature since identifiers are case-sensitive in all real languages like Python, Ruby, C#, Java. [2011-12-03 22:08:24] sg at facelift-bbt dot com This bug was first reported 9 years ago? This definetly got to be fixed. This is a total stopper. I can reproduce it exactly it is shown below. [2011-11-06 19:29:44] gerd dot katzenbeisser at gmail dot com here is a simple test case using the internal class PharFileInfo Output: Locale: C PharFileInfo exists? true Locale: tr_TR.UTF-8 PharFileInfo exists? false [2011-09-16 14:18:21] robin dot bussiek at googlemail dot com @sweiss-at-stylesight thanks for your explanation. Big +1 for any solution to this topic. 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=18556 -- Edit this bug report at https://bugs.php.net/bug.php?id=18556&edit=1
[PHP-BUG] Bug #60462 [NEW]: When APC is enabled segfault
From: Operating system: Mac OS X 10.7 PHP version: 5.4.0RC2 Package: FPM related Bug Type: Bug Bug description:When APC is enabled segfault Description: [master][~/Projects/Test] /usr/local/php5/sbin/php-fpm -i | ack 'error_log' error_log => /usr/local/php5/var/log/php_errors.log => /usr/local/php5/var/log/php_errors.log php-fpm(30748) malloc: *** error for object 0x10122b890: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug zsh: abort /usr/local/php5/sbin/php-fpm -i | zsh: done ack 'error_log' This also happens when using the built in server and when using the apache module when APC is enabled. [APC] apc.enabled = off and the issue stops. php-osx.liip.ch is where the php version is installed from. -- Edit bug report at https://bugs.php.net/bug.php?id=60462&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60462&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60462&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60462&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60462&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60462&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60462&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60462&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60462&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60462&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60462&r=support Expected behavior: https://bugs.php.net/fix.php?id=60462&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60462&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60462&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60462&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60462&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60462&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60462&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60462&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60462&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60462&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60462&r=mysqlcfg
[PHP-BUG] Bug #60463 [NEW]: createcdatasection and ASCII \x10
From:
Operating system: RHEL 6
PHP version: Irrelevant
Package: DOM XML related
Bug Type: Bug
Bug description:createcdatasection and ASCII \x10
Description:
DOMDocument::createCdataSection is leaving ascii control character \x10
which
makes the resulting xml invalid. It seems like this character should be
handled
by the function. Otherwise it ahs to be escaped with:
$dom->createCDATASection(preg_replace('/[\x10]/', '', $value));
Test script:
---
header("Content-type: application/xml; charset=UTF-8");
$dom = new DOMDocument('1.0', 'UTF-8');
$e = $dom->createElement('element');
$dom->appendChild($e);
$e->appendChild($dom->createCDATASection("something\x10something"));
print $dom->saveXml();
exit();
Expected result:
I would expect clean xml.
Actual result:
--
Attempting to read it with DomDocument gives:
DOMDocument::loadXML() [domdocument.loadxml]:
CData section not finished
Opening the above script in chrome gives:
This page contains the following errors:
error on line 2 at column 19: Input is not proper UTF-8, indicate encoding
!
Bytes: 0x10 0x73 0x6F 0x6D
--
Edit bug report at https://bugs.php.net/bug.php?id=60463&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60463&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60463&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60463&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60463&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60463&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60463&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60463&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60463&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60463&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60463&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60463&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60463&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60463&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60463&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60463&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60463&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60463&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60463&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60463&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60463&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60463&r=mysqlcfg
[PHP-BUG] Bug #60465 [NEW]: file_get_contents doesn't stop retrieving data
From: Operating system: Windows PHP version: 5.3.8 Package: HTTP related Bug Type: Bug Bug description:file_get_contents doesn't stop retrieving data Description: When I send request to script connection_close.php from web browser (Internet Explorer, Firefox or Opera), it returns only "1". connection_close.php is run on Apache 2.2 web server. But when I execute this script from other php file via file_get_contents (eg. do_request.php), it returns "12". Test script: --- file connection_close.php: file do_request.php: http://web_server_path/connection_close.php";); ?> Expected result: Executing do_request.php should return "1". Actual result: -- do_request.php returns "12". -- Edit bug report at https://bugs.php.net/bug.php?id=60465&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60465&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60465&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60465&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60465&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60465&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60465&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60465&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60465&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60465&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60465&r=support Expected behavior: https://bugs.php.net/fix.php?id=60465&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60465&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60465&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60465&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60465&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60465&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60465&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60465&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60465&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60465&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60465&r=mysqlcfg
Bug #60461 [Opn->Bgs]: Wrong value outputted
Edit report at https://bugs.php.net/bug.php?id=60461&edit=1 ID: 60461 Updated by: yohg...@php.net Reported by:kodfish01 at yahoo dot com Summary:Wrong value outputted -Status: Open +Status: Bogus Type: Bug Package:Output Control Operating System: windows 7 PHP Version:5.4.0RC2 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2011-12-07 18:02:42] kodfish01 at yahoo dot com Description: --- >From manual page: http://www.php.net/function.floor#refsect1-function.floor- returnvalues --- $diameter = 0.474; //0utput should be 0.5 but floor function rounds the 2 down to 1? $us_ring_size = floor($diameter - 0.458)/0.008) * 0.25; Expected result: 0.5 Actual result: -- 0.25 -- Edit this bug report at https://bugs.php.net/bug.php?id=60461&edit=1
[PHP-BUG] Bug #60467 [NEW]: About 107 auto test [phpt script] failed .
From: Operating system: SLES 11 SP2 PHP version: 5.3.8 Package: Testing related Bug Type: Bug Bug description:About 107 auto test [phpt script] failed . Description: I use the phpt file from php 5.3 tarball package for automation test. 11338 test file , 107 failed , in 107 failed : # 33 test are expect as described in output # 9 test have bug NO. # 66 test is failed 66 test cases are: ./ext/calendar/tests/easter_date.phpt ./ext/calendar/tests/unixtojd.phpt ./ext/date/tests/DateTime_days-spring-type2-type2.phpt ./ext/date/tests/DateTime_days-spring-type2-type3.phpt ./ext/date/tests/DateTime_days-spring-type3-type2.phpt ./ext/date/tests/DateTime_days-spring-type3-type3.phpt ./ext/date/tests/DateTime_sub-dates.phpt ./ext/date/tests/DateTime_sub-february.phpt ./ext/date/tests/timezone_location_get.phpt ./ext/dom/tests/DOMDocument_relaxNGValidate_error2.phpt ./ext/dom/tests/DOMDocument_validate_on_parse_variation.phpt ./ext/gmp/tests/gmp_nextprime.phpt ./ext/intl/tests/resourcebundle_arrayaccess.phpt ./ext/intl/tests/resourcebundle_individual.phpt ./ext/intl/tests/resourcebundle_iterator.phpt ./ext/mysql/tests/001.phpt ./ext/mysql/tests/mysql_connect.phpt ./ext/mysql/tests/mysql_max_links.phpt ./ext/mysql/tests/mysql_sql_safe_mode.phpt ./ext/mysqli/tests/mysqli_connect.phpt ./ext/mysqli/tests/mysqli_connect_oo.phpt ./ext/mysqli/tests/mysqli_connect_oo_defaults.phpt ./ext/pcre/tests/006.phpt ./ext/pdo_mysql/tests/pdo_mysql___construct_options.phpt ./ext/pdo_mysql/tests/pdo_mysql_interface.phpt ./ext/posix/tests/posix_ttyname_error.phpt ./ext/posix/tests/posix_ttyname_variation1.phpt ./ext/posix/tests/posix_ttyname_variation2.phpt ./ext/posix/tests/posix_ttyname_variation3.phpt ./ext/posix/tests/posix_ttyname_variation4.phpt ./ext/posix/tests/posix_ttyname_variation5.phpt ./ext/posix/tests/posix_ttyname_variation6.phpt ./ext/posix/tests/posix_ttyname_variation7.phpt ./ext/session/tests/014.phpt ./ext/session/tests/015.phpt ./ext/session/tests/018.phpt ./ext/session/tests/020.phpt ./ext/session/tests/021.phpt ./ext/session/tests/session_id_variation2.phpt ./ext/sockets/tests/socket_strerror.phpt ./ext/spl/examples/tests/dualiterator_001.phpt ./ext/sqlite/tests/sqlite_session_001.phpt ./ext/sqlite/tests/sqlite_session_002.phpt ./ext/sqlite3/tests/sqlite3_prepare_001.phpt ./ext/standard/tests/class_object/is_a_error_001.phpt ./ext/standard/tests/class_object/is_subclass_of_error_001.phpt ./ext/standard/tests/general_functions/getservbyname_variation10.phpt ./ext/standard/tests/general_functions/getservbyname_variation9.phpt ./ext/standard/tests/general_functions/getservbyport_variation1.phpt ./ext/standard/tests/general_functions/phpinfo.phpt ./ext/standard/tests/general_functions/proc_nice_variation5.phpt ./ext/standard/tests/misc/time_sleep_until_basic.phpt ./ext/standard/tests/php_ini_loaded_file.phpt ./ext/standard/tests/strings/htmlentities02.phpt ./ext/standard/tests/strings/htmlentities04.phpt ./ext/standard/tests/strings/htmlentities10.phpt ./ext/standard/tests/strings/htmlentities11.phpt ./ext/standard/tests/strings/htmlentities13.phpt ./ext/standard/tests/strings/htmlentities15.phpt ./ext/standard/tests/strings/setlocale_variation2.phpt ./ext/xsl/tests/xslt010.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcnostring.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcundef.phpt ./sapi/cli/tests/001.phpt ./sapi/cli/tests/015.phpt Test script: --- only one line script env TEST_PHP_EXECUTABLE=/usr/bin/php REPORT_EXIT_STATUS=1 TEST_PHP_SRCDIR=/usr/share/qa/qa_test_php53 TEST_PHP_DETAILED=1 NO_INTERACTION=1 /usr/bin/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/share/qa/qa_test_php53/run-tests.php [phpt.file] Expected result: 65 test cases should pass? Actual result: -- 65 test cases failed -- Edit bug report at https://bugs.php.net/bug.php?id=60467&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60467&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60467&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60467&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60467&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60467&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60467&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60467&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60467&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60467&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60467&r=support Expected behavior: https://bugs.php.net/fix.php?id=60467&r=notwrong Not enough info:
