Req #64871 [Opn]: The ::class operator should verify the class name
Edit report at https://bugs.php.net/bug.php?id=64871edit=1 ID: 64871 Updated by: vr...@php.net Reported by:vr...@php.net Summary:The ::class operator should verify the class name Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:5.5.0RC1 -Assigned To: +Assigned To:ralphschindler Block user comment: N Private report: N New Comment: Ralph, what's your take on this? Previous Comments: [2013-05-17 16:48:42] vr...@php.net Description: One of the main advantages of the ::class operator could be that it verifies the class name upon creating the string instead of upon usage. It should trigger autoloading if the class doesn't exist. I know that it's somewhat late to change this in PHP 5.5 but I was really surprised by the lack of this feature and about the fact that it wasn't considered in RFC. Test script: --- ?php // I want to know about this typo. echo stdClas::class; Expected result: Fatal error: Class 'stdClas' not found Actual result: -- stdClas -- Edit this bug report at https://bugs.php.net/bug.php?id=64871edit=1
Req #64871 [Wfx]: The ::class operator should verify the class name
Edit report at https://bugs.php.net/bug.php?id=64871edit=1 ID: 64871 Updated by: vr...@php.net Reported by:vr...@php.net Summary:The ::class operator should verify the class name Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:5.5.0RC1 Assigned To:ralphschindler Block user comment: N Private report: N New Comment: Makes sense, thanks for the explanation. Previous Comments: [2013-05-17 17:16:08] ralphschind...@php.net I believe this came up, and I wouldn't support this. This would be inconsistent with the current implementation of namespaces. use Foo\Bar\Baz; for example, does not check the existence of Baz on use. It is not not till a type is used (either statically called or used to create a new instance of via new) that it will trigger autoloading (if there is one). There are many places in PHP where type names are used, method signatures, and even in the following example: $x = new stdClass; var_dump($x instanceof FooBar); PHP will not attempt to autoload FooBar to for the purposes of instanceof. If you need to know that a particular type exists, class_exists(foo::class, true); should do what you need. If you feel differently, I think you should bring this up on the internals mailing list. [2013-05-17 16:49:21] vr...@php.net Ralph, what's your take on this? [2013-05-17 16:48:42] vr...@php.net Description: One of the main advantages of the ::class operator could be that it verifies the class name upon creating the string instead of upon usage. It should trigger autoloading if the class doesn't exist. I know that it's somewhat late to change this in PHP 5.5 but I was really surprised by the lack of this feature and about the fact that it wasn't considered in RFC. Test script: --- ?php // I want to know about this typo. echo stdClas::class; Expected result: Fatal error: Class 'stdClas' not found Actual result: -- stdClas -- Edit this bug report at https://bugs.php.net/bug.php?id=64871edit=1
Req #64871 [Wfx]: The ::class operator should verify the class name
Edit report at https://bugs.php.net/bug.php?id=64871edit=1 ID: 64871 Updated by: vr...@php.net Reported by:vr...@php.net Summary:The ::class operator should verify the class name Status: Wont fix Type: Feature/Change Request Package:Class/Object related Operating System: Any PHP Version:5.5.0RC1 Assigned To:ralphschindler Block user comment: N Private report: N New Comment: Ralph, David is referring to https://bugs.php.net/61467. I agree that this is not the best place for the discussion about that. Previous Comments: [2013-05-17 20:13:20] ralphschind...@php.net David, I am not sure what behavior you're referencing. When does callable trigger autoload? Perhaps this is a conversation for the internals mailing list? [2013-05-17 18:34:04] David at grudl dot com Ralph, totally agree. What do you think about fixing type hint callable to not trigger autoloading? [2013-05-17 18:23:40] vr...@php.net Makes sense, thanks for the explanation. [2013-05-17 17:16:08] ralphschind...@php.net I believe this came up, and I wouldn't support this. This would be inconsistent with the current implementation of namespaces. use Foo\Bar\Baz; for example, does not check the existence of Baz on use. It is not not till a type is used (either statically called or used to create a new instance of via new) that it will trigger autoloading (if there is one). There are many places in PHP where type names are used, method signatures, and even in the following example: $x = new stdClass; var_dump($x instanceof FooBar); PHP will not attempt to autoload FooBar to for the purposes of instanceof. If you need to know that a particular type exists, class_exists(foo::class, true); should do what you need. If you feel differently, I think you should bring this up on the internals mailing list. [2013-05-17 16:49:21] vr...@php.net Ralph, what's your take on this? 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=64871 -- Edit this bug report at https://bugs.php.net/bug.php?id=64871edit=1
Bug #64863 [Opn]: PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build
Edit report at https://bugs.php.net/bug.php?id=64863edit=1 ID: 64863 Updated by: vr...@php.net Reported by:vr...@php.net Summary:PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build Status: Open Type: Bug Package:*Compile Issues Operating System: Windows 64bit PHP Version:5.5.0RC1 -Assigned To: +Assigned To:szarkos Block user comment: N Private report: N New Comment: Steve, can you please take a look? Previous Comments: [2013-05-16 18:20:01] vr...@php.net Description: I want to work with DB bigint data type without troubles, I want to call mysql_insert_id() safely. Also some problems in Google Code Jam require 8 bytes int and it's very hard to solve them with 4 bytes int because BC is too slow. I know that this might be by design but it is a bad design. Especially given that Linux 64 bits builds have 8 bytes int. Also the main advantage of 64 bits is to be able to use these 64 bits. Test script: --- ?php echo PHP_INT_SIZE; // with php-5.5.0RC1-Win32-VC11-x64.zip Expected result: 8 Actual result: -- 4 -- Edit this bug report at https://bugs.php.net/bug.php?id=64863edit=1
Bug #64849 [Opn]: imagescale() ignores method parameter
Edit report at https://bugs.php.net/bug.php?id=64849edit=1 ID: 64849 Updated by: vr...@php.net Reported by:vr...@php.net Summary:imagescale() ignores method parameter Status: Open Type: Bug Package:GD related Operating System: Any PHP Version:5.5.0RC1 -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: Pierre, can you please take a look? Previous Comments: [2013-05-15 19:29:14] vr...@php.net Description: See https://github.com/php/php-src/blob/php-5.5.0RC1/ext/gd/gd.c#L5076. -- Edit this bug report at https://bugs.php.net/bug.php?id=64849edit=1
Bug #64851 [Opn]: DateTimeImmutable::createFromFormat() returns DateTime
Edit report at https://bugs.php.net/bug.php?id=64851edit=1
ID: 64851
Updated by: vr...@php.net
Reported by:vr...@php.net
Summary:DateTimeImmutable::createFromFormat() returns
DateTime
Status: Open
Type: Bug
Package:Date/time related
Operating System: Any
PHP Version:5.5.0RC1
-Assigned To:
+Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Derick, can you please take a look?
Previous Comments:
[2013-05-15 23:01:19] vr...@php.net
Description:
It should return DateTimeImmutable.
Test script:
---
?php
echo get_class(DateTimeImmutable::createFromFormat('j-M-Y', '15-Feb-2009'));
?
Expected result:
DateTimeImmutable
Actual result:
--
DateTime
--
Edit this bug report at https://bugs.php.net/bug.php?id=64851edit=1
Bug #64513 [Opn-Csd]: DateTimeImmutable is incompatible with DateTime and leads to BC breaks
Edit report at https://bugs.php.net/bug.php?id=64513edit=1
ID: 64513
Updated by: vr...@php.net
Reported by:bugs dot php dot net at majkl578 dot cz
Summary:DateTimeImmutable is incompatible with DateTime and
leads to BC breaks
-Status: Open
+Status: Closed
Type: Bug
Package:Date/time related
Operating System: -
PHP Version:5.5.0beta1
-Assigned To:
+Assigned To:vrana
Block user comment: N
Private report: N
New Comment:
DateTimeImmutable doesn't inherit from DateTime in PHP 5.5.0RC1 anymore.
Previous Comments:
[2013-03-25 17:19:02] bugs dot php dot net at majkl578 dot cz
Description:
PHP 5.5 adds DateTimeImmutable, which extends DateTime.
As Benjamin Eberlei already pointed out in internals list [1], the behavior is
not compatible with each other and therefore the inheritance seems to be wrong.
This bad implementation is not backward compatible and may lead to serious
problems with existing code.
Here are some examples which would get broken (bad behavior or even infinite
loop!) by passing DateTimeImmutable instead of DateTime.
function testOne(DateTime $dt)
{
for ($i = 1; $i = 2; $i++, $dt-modify('first day of next month')) {
echo $dt-format('Y/m/d'), PHP_EOL;
}
}
testOne(new DateTime());
// 2013/03/25
// 2013/04/01
testOne(new DateTimeImmutable());
// 2013/03/25
// 2013/03/25
---
function testTwo(DateTime $from, DateTime $to)
{
for ($current = clone $from; $current = $to; $current-modify('+ 1
day')) {
echo $current-format('Y/m/d'), PHP_EOL;
}
}
testTwo(new DateTime(), new DateTime('+ 1 day'));
// 2013/03/25
// 2013/03/26
testTwo(new DateTimeImmutable(), new DateTimeImmutable('+ 1 day'));
// 2013/03/25
// 2013/03/25
// 2013/03/25
// infinite loop occurs!
This clearly shows what side-effects might this feature have.
Please, do not add another badly designed feature and revert it before 5.5 gets
released.
[1] http://marc.info/?l=php-internalsm=136135370215794w=2
--
Edit this bug report at https://bugs.php.net/bug.php?id=64513edit=1
Bug #64852 [Opn]: Allow binding arrays in PDO
Edit report at https://bugs.php.net/bug.php?id=64852edit=1
ID: 64852
Updated by: vr...@php.net
Reported by:vr...@php.net
Summary:Allow binding arrays in PDO
Status: Open
Type: Bug
Package:PDO related
Operating System: Any
PHP Version:5.5.0RC1
-Assigned To:
+Assigned To:wez
Block user comment: N
Private report: N
New Comment:
Wez, do you think it's reasonable?
Previous Comments:
[2013-05-16 05:22:04] vr...@php.net
Description:
Binding arrays would be useful in these queries:
WHERE id IN ?
INSERT INTO ... VALUES ?
Most database systems don't support binding complex data structures on server
side but PDO supports client side data binding so it can expand arrays to
scalars and use them. Example:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN ?);
$stmt-execute([ array('1', '2', '3') ]);
// This will be executed with client side data binding:
// SELECT * FROM table WHERE id IN ('1', '2', '3')
// With server side data binding:
// SELECT * FROM table WHERE id IN (?, ?, ?) -- bind values: '1', '2', '3'
?
It means that with server side data binding, arrays will be expanded to
variable number of placeholders and the elements in the array will be bound.
There is a risk that the same statement would be used with a differently
structured array or with non-array. Example:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN ?);
// Expands query to: SELECT * FROM table WHERE id IN (?, ?, ?)
$stmt-execute([ array(1, 2, 3) ]);
// This subsequent call should throw.
$stmt-execute([ array(1, 2, 3, 4) ]);
// This subsequent call should also throw.
$stmt-execute([ 1 ]);
?
This is a very rare usage and throwing an error in this case seems like a good
solution.
=== Named parameters ===
Named parameters could expand to name-key pair:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN :ids);
// Expands query to: SELECT * FROM table WHERE id IN (:ids_0, :ids_1, :ids_2)
$stmt-execute([ 'ids' = array(1, 2, 3) ]);
?
However, there could be a collision: WHERE id = :ids_0 OR id IN :ids. PDO
could solve it by some sort of escaping - e.g. by prepending a magic string to
all array names or by prepending something else also to all non-array names. Or
it could just throw as this would be a rare and easily fixable problem.
=== Nested arrays ===
Expanding arrays should be recursive to support these queries:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE (type, type_id) IN ?);
// Expands to SELECT * FROM table WHERE (type, type_id) IN ((?, ?), (?, ?))
$types = array();
$types[] = array('article', 1);
$types[] = array('comment', 11);
$stmt-execute([ $types ]);
?
=== Braces or no braces ===
Array should expand to comma-delimited, braces-enclosed string. This expansion
would support queries WHERE (type, type_id) IN ?. It unfortunately wouldn't
support this query:
INSERT INTO ... VALUES (...), (...), ...
This query needs braces in inner array and no braces in outer array so there's
no consistent way to support this type of query.
=== Empty arrays ===
Empty arrays should be treated same as other arrays so they should expand to
(). INSERT INTO table () VALUES () is a valid query, at least in MySQL (it
inserts a row with all default values). This would cause a syntax error in
query WHERE id IN () but that's a good behavior as there's no way to tell
database to not match anything. WHERE id IN (NULL) would be a solution in
this particular query (as NULL doesn't equal to NULL) but WHERE id NOT IN
(NULL) wouldn't return NULL rows. So empty array must expand to ().
=== Debugging ===
PDO should disclose a method returning the real query sent to the server. It
would be useful even without arrays, especially with client-side binding.
=== Implementation ===
Implementation would be tricky as the statement couldn't be prepared until it's
executed. It means that PDO wouldn't talk to the database server in prepare()
even with server-side binding (this is the current behavior with client-side
binding). The query would be both prepared and executed in execute().
--
Edit this bug report at https://bugs.php.net/bug.php?id=64852edit=1
Bug #64552 [Asn-Csd]: Some extensions missing from x64 Windows distribution
Edit report at https://bugs.php.net/bug.php?id=64552edit=1 ID: 64552 Updated by: vr...@php.net Reported by:vr...@php.net Summary:Some extensions missing from x64 Windows distribution -Status: Assigned +Status: Closed Type: Bug Package:Windows Installer Operating System: Windows PHP Version:5.5.0beta1 Assigned To:szarkos Block user comment: N Private report: N New Comment: It works, thanks. Previous Comments: [2013-04-02 17:56:47] szar...@php.net Hello, This should be fixed now. The extensions should build properly and show up in the latest 5.5 x64 snapshot builds, probably within the next 24-hours at the latest. You can find the latest snapshots here: http://windows.php.net/downloads/snaps/php-5.5/ Thanks, Steve [2013-03-31 08:08:14] paj...@php.net Steve, can you take a look please? [2013-03-30 19:30:17] vr...@php.net Description: I've downloaded php-5.5.0beta2-Win32-VC11-x64.zip from http://windows.php.net/qa/ and there's bunch of extensions missing compared to x86 distributions: php_gd2.dll php_gettext.dll php_oci8.dll php_oci8_11g.dll php_pdo_oci.dll -- Edit this bug report at https://bugs.php.net/bug.php?id=64552edit=1
Bug #61467 [Fbk-Opn]: New callable typehint does not work (autoloading)
Edit report at https://bugs.php.net/bug.php?id=61467edit=1
ID: 61467
Updated by: vr...@php.net
Reported by:david at grudl dot com
Summary:New callable typehint does not work (autoloading)
-Status: Feedback
+Status: Open
Type: Bug
Package:Class/Object related
PHP Version:5.4.0
Block user comment: N
Private report: N
Previous Comments:
[2012-03-21 23:57:25] david at grudl dot com
Possible fix is to change in file zend_execute.c on line 645 flag
IS_CALLABLE_CHECK_SILENT to IS_CALLABLE_CHECK_SYNTAX_ONLY.
[2012-03-21 21:58:51] david at grudl dot com
Sorry, in PHP 5.4 there is not an instance of in error message. But that's
not the point.
[2012-03-21 20:49:54] ras...@php.net
Are you sure you are running 5.4? Your your test script:
% php53 test.php
Catchable fatal error: Argument 1 passed to test() must be an instance of
callable, array given, called in /home/rasmus/r on line 6 and defined in
/home/rasmus/r on line 2
% php54 test.php
Catchable fatal error: Argument 1 passed to test() must be callable, array
given, called in /home/rasmus/r on line 6 and defined in /home/rasmus/r on line
2
[2012-03-21 20:25:04] david at grudl dot com
do - does
[2012-03-21 20:22:00] david at grudl dot com
Description:
Is really new type hint callable implemented? I see no difference between PHP
5.3 and PHP 5.4, both versions only throw catchable fatal errors.
(I think this unexpected behaviour is due to the fact that class A do not
exists. In this case the error message is confusing. But the callable should
not trigger autoload, it should behave like is_callable($arg, TRUE) and just
check the syntax. Otherwise typehint callable will cause major performance
issues.)
Test script:
---
function test(callable $a)
{
}
test(array('A', 'b'));
// Catchable fatal error: Argument 1 passed to test() must be an instance of
callable, array given
test('A::b');
// Catchable fatal error: Argument 1 passed to test() must be an instance of
callable, string given
--
Edit this bug report at https://bugs.php.net/bug.php?id=61467edit=1
Bug #55056 [Csd-ReO]: missing php_gd2.dll in windows.php.net builds
Edit report at https://bugs.php.net/bug.php?id=55056edit=1 ID: 55056 Updated by: vr...@php.net Reported by:giorgio dot liscio at email dot it Summary:missing php_gd2.dll in windows.php.net builds -Status: Closed +Status: Re-Opened Type: Bug Package:*General Issues Operating System: windows -PHP Version:5.4.0alpha1 +PHP Version:5.4.0RC7 Assigned To:pajoye Block user comment: N Private report: N New Comment: The file is missing in php-5.4.0RC7-nts-Win32-VC9-x86.zip. Previous Comments: [2011-06-28 18:59:54] paj...@php.net Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Fixed, there was a bug in the scripts. Snaps and alpha1 should have the missing exts now. [2011-06-28 17:37:31] giorgio dot liscio at email dot it Description: hi, php_gd2.dll is missing in the windows snaps of 5.4 and trunk (vc9 ts) http://windows.php.net/downloads/snaps/php-5.4/ if you download any of this you will not find the php_gd2.dll thanks in advance -- Edit this bug report at https://bugs.php.net/bug.php?id=55056edit=1
Bug #55101 [Opn]: Reflection tries to find symlink() and readlink() when they don't exist
Edit report at https://bugs.php.net/bug.php?id=55101edit=1
ID: 55101
Updated by: vr...@php.net
Reported by:vr...@php.net
-Summary:Functions symlink() and readlink() are missing on
Windows Vista
+Summary:Reflection tries to find symlink() and readlink()
when they don't exist
Status: Open
Type: Bug
Package:Reflection related
Operating System: Windows XP
PHP Version:5.4.0alpha1
Block user comment: N
Private report: N
New Comment:
I know, it is even mentioned in the bug report. The problem is that Reflection
doesn't know it and produces an Internal error.
Previous Comments:
[2011-07-01 09:06:29] paj...@php.net
re-open, but really not sure if it is fixable in reflexion, but there is no bug
in
these functions per se :)
[2011-07-01 09:04:46] paj...@php.net
They are also dynamically available, we remove them at init time if the Windows
version is vista.
[2011-07-01 09:03:54] paj...@php.net
They are only available in vista and later.
[2011-07-01 08:54:29] vr...@php.net
The first line of Test script should be:
var_dump(function_exists('readlink'));
It outputs bool(false) mentioned in the result.
[2011-07-01 08:51:51] vr...@php.net
Description:
These two functions are available on Windows = Vista since PHP 5.3.0. The
problem is that reflection have some pointers on them even in Windows Vista
(e.g. XP) where they are not available.
Test script:
---
?php
$r = new ReflectionExtension(standard);
$r-getFunctions();
?
Expected result:
bool(false)
Actual result:
--
bool(false)
Warning: ReflectionExtension::getFunctions(): Internal error: Cannot find
extension function readlink in global function table
Warning: ReflectionExtension::getFunctions(): Internal error: Cannot find
extension function symlink in global function table
--
Edit this bug report at https://bugs.php.net/bug.php?id=55101edit=1
Bug #55101 [Opn]: Reflection tries to find symlink() and readlink() when they don't exist
Edit report at https://bugs.php.net/bug.php?id=55101edit=1 ID: 55101 Updated by: vr...@php.net Reported by:vr...@php.net Summary:Reflection tries to find symlink() and readlink() when they don't exist Status: Open Type: Bug Package:Reflection related Operating System: Windows XP PHP Version:5.4.0alpha1 Block user comment: N Private report: N New Comment: I've looked in the source codes but I didn't get a clue how is it achieved that readlink() is disabled on Windows Vista. I also don't see anything related at http://lxr.php.net/search?project=PHP_5_4refs=readlink Previous Comments: [2011-07-01 09:19:47] paj...@php.net It certainly does something nasty, can you try to figure out where pls? [2011-07-01 09:07:36] vr...@php.net I know, it is even mentioned in the bug report. The problem is that Reflection doesn't know it and produces an Internal error. [2011-07-01 09:06:29] paj...@php.net re-open, but really not sure if it is fixable in reflexion, but there is no bug in these functions per se :) [2011-07-01 09:04:46] paj...@php.net They are also dynamically available, we remove them at init time if the Windows version is vista. [2011-07-01 09:03:54] paj...@php.net They are only available in vista and later. 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=55101 -- Edit this bug report at https://bugs.php.net/bug.php?id=55101edit=1
Bug #53782 [Bgs-ReO]: foreach throws irrelevant exception
Edit report at http://bugs.php.net/bug.php?id=53782edit=1
ID: 53782
Updated by: vr...@php.net
Reported by:david at grudl dot com
Summary:foreach throws irrelevant exception
-Status: Bogus
+Status: Re-Opened
Type: Bug
Package:PDO related
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This seems like a real bug, example is correct.
Previous Comments:
[2011-05-10 14:37:33] david at grudl dot com
This is a serious bug in the PDO. Look at the example more closely.
Variable $res has nothing to do with errenous query.
[2011-05-10 10:06:47] u...@php.net
Running errenous query and not expecting exception is bogus.
[2011-01-18 21:30:47] david at grudl dot com
Description:
Iteration using foreach throws previous and irrelevant exception.
Exception is throwed after last iteration.
Test script:
---
$conn = new PDO(mysql:dbname=test);
$conn-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$res = $conn-query('SELECT * FROM categories');
try {
$conn-query('ERROR');
} catch (PDOException $e) { // exception is catched
}
foreach ($res as $k = $v); // now is throwed exception $e !!!
Expected result:
do nothing
--
Edit this bug report at http://bugs.php.net/bug.php?id=53782edit=1
Bug #53805 [Tbd-Csd]: filter_input_array ommits SERVER['REQUEST_TIME'] input
Edit report at http://bugs.php.net/bug.php?id=53805edit=1
ID: 53805
Updated by: vr...@php.net
Reported by:it at x-trader dot cz
Summary:filter_input_array ommits SERVER['REQUEST_TIME']
input
-Status: To be documented
+Status: Closed
Type: Bug
Package:Filter related
Operating System: linux
PHP Version:Irrelevant
-Assigned To:
+Assigned To:vrana
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Only REQUEST_TIME is missing.
Previous Comments:
[2011-02-05 14:33:05] ka...@php.net
.
[2011-01-21 21:23:19] it at x-trader dot cz
Thank you for your prompt response.
From the user doesn't come many other SERVER variables, for example:
REDIRECT_STATUS, PATH, DOCUMENT_ROOT, SCRIPT_FILENAME,
GATEWAY_INTERFACE, SERVER_PROTOCOL, REQUEST_METHOD, SCRIPT_NAME,
PHP_SELF etc.
Should be at least documented.
[2011-01-21 20:34:39] ras...@php.net
REQUEST_TIME doesn't come from the user. It is added to the $_SERVER
array after
input filtering runs.
[2011-01-21 20:30:53] it at x-trader dot cz
Description:
Function filter_input_array does NOT return from SERVER input variable
REQUEST_TIME key = value pair.
Tested on Linux, PHP versions 5.2.8 and 5.3.2.
May be it's undocumented feature or filter implementation failure,
because filter functions are using only the original variable values
passed to PHP.
Test script:
---
?php
var_dump(array_diff($_SERVER, filter_input_array(INPUT_SERVER,
FILTER_UNSAFE_RAW)));
Expected result:
array(0)
{
}
Actual result:
--
array(1)
{
'REQUEST_TIME' = int(1295636581)
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=53805edit=1
Bug #53597 [Tbd-Csd]: open_basedir not working as documented
Edit report at http://bugs.php.net/bug.php?id=53597edit=1 ID: 53597 Updated by: vr...@php.net Reported by:hsk at fli-leibniz dot de Summary:open_basedir not working as documented -Status: To be documented +Status: Closed Type: Bug Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.4 Assigned To:pajoye Block user comment: N Private report: N New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2011-01-12 17:25:07] chroom dot chroom at gmail dot com 1 I confirm: open_basedir does not act as prefix I experience the same problem with an earlier version: PHP 5.3.2 (API 20090626) on 32-bit Ubuntu 10.04. 2 A new case: open_basedir ending with a slash blocks PHP Another problem with the same config option is: path ending with a slash practically blocks PHP in an annoying way. With open_basedir set to /var/www/ it is expected to be able to serve files from this directory, but it doesn't work. This is not only different from the docs, this is nonsense. It's the behaviour that should be changed, not only the docs. So please change the bug status. This excerpt from errorlog documents this absurd: PHP Warning: Unknown: open_basedir restriction in effect. File(/var/ www/bits.php) is not within the allowed path(s): (/var/www/) in Unknown on line 0 [2011-01-10 16:31:14] paj...@php.net Docs need to be updated but that won't change. [2011-01-10 16:31:11] paj...@php.net Docs need to be updated but that won't change. [2011-01-10 15:34:55] ahar...@php.net Ah, I see what you're getting at now. My apologies for closing the bug. [2011-01-10 14:38:23] hsk at fli-leibniz dot de #53597 is definitely *not* a duplicate of #53577, please change status open_basedir as of 5.3.4 (and 5.3.5 as well) no longer allows to specify directory prefixes, in contradiction to the documentation e.g., setting open_basedir = /u/phpMyAdmin should accept files in /u/phpMyAdmin-3.3.8.1-all-languages, but does not 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=53597 -- Edit this bug report at http://bugs.php.net/bug.php?id=53597edit=1
Bug #53319 [Tbd-Csd]: strip_tags() may strip 'br /' incorrectly
Edit report at http://bugs.php.net/bug.php?id=53319edit=1 ID: 53319 Updated by: vr...@php.net Reported by:Ray dot Paseur at Gmail dot com Summary:strip_tags() may strip 'br /' incorrectly -Status: To be documented +Status: Closed Type: Bug Package:Strings related Operating System: Linux PHP Version:5.3.3 -Assigned To: +Assigned To:vrana Block user comment: N Private report: N New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2011-02-10 17:09:24] vr...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2010-11-17 03:01:13] Ray dot Paseur at Gmail dot com Thanks, Felipe! [2010-11-16 23:21:15] fel...@php.net I've fixed the bug related to 'br' is stripping br/ in the string. About strip_tags($str, 'br/'): The allowed tags should not contains slash char. This must be documented though. [2010-11-16 23:16:46] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=305418 Log: - Fixed bug #53319 (strip_tags() may strip 'lt;br /gt;' incorrectly) [2010-11-16 01:22:26] Ray dot Paseur at Gmail dot com Description: --- From manual page: http://www.php.net/function.strip-tags#Return Values --- Test script: --- ?php // RAY_strip_tags_anomaly.php error_reporting(E_ALL); // SELF-CLOSING TAGS WITH SPACES $str = 'tdUSDbr /br /CDN/td'; $new = strip_tags($str); echo $new; // Prints USDCDN // TRY TO PRESERVE ALLOWABLE TAGS $new = strip_tags($str, 'br /'); echo $new; // Prints USDCDN -- The break tag is not preserved $new = strip_tags($str, 'br'); echo $new; // Prints USDbr /br /CDN // SELF-CLOSING TAGS WITHOUT SPACES $str = 'tdUSDbr/br/CDN/td'; $new = strip_tags($str, 'br/'); echo $new; // Prints USDbr/br/CDN Expected result: strip_tags() should preserve the allowable_tags Actual result: -- strip_tags did not always preserve the allowable_tags -- Edit this bug report at http://bugs.php.net/bug.php?id=53319edit=1
Bug #52400 [Tbd-Bgs]: Object 'named' constructor not called in namespaces only
Edit report at http://bugs.php.net/bug.php?id=52400edit=1
ID: 52400
Updated by: vr...@php.net
Reported by:mat999 at gmail dot com
Summary:Object 'named' constructor not called in namespaces
only
-Status: To be documented
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: linux, debian
PHP Version:5.3.3RC3
Block user comment: N
Private report: N
New Comment:
Already documented at http://php.net/language.oop5.decon
As of PHP 5.3.3, methods with the same name as the last element of a
namespaced class name will no longer be treated as constructor. This
change doesn't affect non-namespaced classes.
Previous Comments:
[2010-07-22 10:17:25] paj...@php.net
@doc
Can you check if it is in there already as well as in the manual?
[2010-07-22 10:09:00] mat999 at gmail dot com
Thanks for the quick reply, can I recomend adding this to the UPGRADING
document?
[2010-07-22 10:01:36] paj...@php.net
By design, bug fix.
Methods with the same name as the last element of a namespaced class
name will not be treated as constructor anymore. This change doesn't
affect non-namespaced classes.
Use the recommended __construct instead.
[2010-07-22 09:58:43] mat999 at gmail dot com
Description:
Very big bad bug, suprised it escaped test until now. Only tested on
php-fpm, not cli.
Test script:
---
namespace NS1 {
class Test {
function Test($t){
die('called');
}
}
}
namespace {
new \NS1\Test($t);
die(':(');
}
Expected result:
called
Actual result:
--
:(
--
Edit this bug report at http://bugs.php.net/bug.php?id=52400edit=1
Bug #52120 [Fbk-Opn]: Unable to call inherited protected __construct
Edit report at http://bugs.php.net/bug.php?id=52120edit=1
ID: 52120
Updated by: vr...@php.net
Reported by: vr...@php.net
Summary: Unable to call inherited protected __construct
-Status: Feedback
+Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: *
PHP Version: 5.3.2
New Comment:
?php
class A {
protected function f() {
}
}
class B extends A {
static function test() {
$c = new C;
$c-f();
}
}
class C extends A {
protected function f() {
echo OK\n;
}
}
B::test();
?
This should output OK which it really does.
Previous Comments:
[2010-06-20 00:39:10] fel...@php.net
This is true for all methods except __construct().
Can you provide an test case for non __construct method? I cannot
reproduce it.
[2010-06-18 17:15:42] vr...@php.net
Description:
Protected visibility allows accessing parent members and also members of
parent's children. If class A defines protected method f() and classes B
and C are children of A then B can call C::f(). This is true for all
methods except __construct().
Test script:
---
class A {
protected function __construct() {
}
}
class B extends A {
static function test() {
new C;
}
}
class C extends A {
protected function __construct() {
echo OK\n;
}
}
B::test();
Expected result:
OK
Actual result:
--
Fatal error: Call to protected C::__construct() from context 'B' on line
9
--
Edit this bug report at http://bugs.php.net/bug.php?id=52120edit=1
#50184 [Tbd-Csd]: Constants can be redefined
ID: 50184
Updated by: vr...@php.net
Reported By: goatlabs at gmail dot com
-Status: To be documented
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: OSX 10.6.2; Debian Linux 5.0.3
PHP Version: 5.3.0
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2009-11-25 09:59:33] s...@php.net
Automatic comment from SVN on behalf of vrana
Revision: http://svn.php.net/viewvc/?view=revisionrevision=291296
Log: Case-insensitive are lower-case (bug #50184)
[2009-11-16 09:35:44] j...@php.net
From manual notes:
A note on redefining:
Constants can't be redefined:
$ php -r define('A', 1); var_dump('A'); define('A', 2);
var_dump('A');;
string(1) A
PHP Notice: Constant A already defined in Command line code on line 1
string(1) A
But using the case insensitive setting shows that the internal
representation is lower case:
$ php -r define('A', 1, true); var_dump('A'); define('A', 2);
var_dump('A');;
string(1) A
string(1) A
Note the lower case 'a' in the second define() here:
$ php -r define('A', 1, true); var_dump('A'); define('a', 2);
var_dump('A');;
string(1) A
PHP Notice: Constant a already defined in Command line code on line 1
string(1) A
(Short version: Yes, but no)
[2009-11-16 03:59:24] goatlabs at gmail dot com
Note: the description should read:
define() constants can be modified if originally defined
case-INsensitive
[2009-11-16 01:44:49] goatlabs at gmail dot com
Description:
define() constants can be modified if originally defined case-sensitive
Reproduce code:
---
define('TEST', 'foo', true);
var_dump(TEST);
define('TEST', 'bar');
var_dump(TEST);
Expected result:
string(3) foo
string(3) foo
Actual result:
--
string(3) foo
string(3) bar
--
Edit this bug report at http://bugs.php.net/?id=50184edit=1
#48167 [Tbd-Csd]: undefined function checkdnsrr()
ID: 48167 Updated by: vr...@php.net Reported By: frew dot robert at gmail dot com -Status: To be documented +Status: Closed Bug Type: *Network Functions Operating System: Linux PHP Version: 5.3.0RC1 Assigned To: fa New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2009-11-25 10:37:37] vr...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2009-05-11 09:38:08] ka...@php.net Alot of functions may not be available if the configure script does not find them on Unix, wheres on Windows they are either available or not, not *maybe*. We really need to list these in the manual [2009-05-06 21:19:11] frew dot robert at gmail dot com Recompiled PHP and the problem went away. [2009-05-06 19:34:39] paj...@php.net Yes, set it as to be documented. Please not that as in 5.3, it is always available on windows. [2009-05-06 19:30:46] f...@php.net That's not mentioned in the documentation, shouldn't this be converted to a documentation bug then? 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/48167 -- Edit this bug report at http://bugs.php.net/?id=48167edit=1
#47752 [Tbd-Csd]: FILTER_VALIDATE_INT doesn't allow +0 and -0
ID: 47752
Updated by: vr...@php.net
Reported By: for-bugs at hnw dot jp
-Status: To be documented
+Status: Closed
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
Previous Comments:
[2009-11-25 10:41:57] s...@php.net
Automatic comment from SVN on behalf of vrana
Revision: http://svn.php.net/viewvc/?view=revisionrevision=291299
Log: Numbers +0 and -0 (bug #47752)
[2009-03-24 16:20:07] scott...@php.net
The documentation should probably mention that +0 and -0 are valid
floats.
var_dump(filter_var(+0, FILTER_VALIDATE_FLOAT));
var_dump(filter_var(-0, FILTER_VALIDATE_FLOAT));
[2009-03-24 15:22:37] paj...@php.net
Make it a documentation bug instead, it should be documented and will
be, will add some other things while being at it :)
[2009-03-24 15:15:17] paj...@php.net
We have double checked again the design choices about -/+ 0, it was on
purpose. -0 or +0 are not valid integers.
Sorry, but we have to reject this request.
thanks for your understanding,
[2009-03-24 15:03:53] peter at lvp-media dot com
Hereby a simple bug47752.phpt file. Tested it on a patched- an an
unpatched installation, results as expected. Strictly speaking +0 and -0
are valid integers, even though neither of them is positive or
negative.
Peter Beverloo
--TEST--
Bug #47752 (FILTER_VALIDATE_INT doesn't allow +0 and -0)
--FILE--
?php
$positive = filter_var ('+0', FILTER_VALIDATE_INT);
$negative = filter_var ('-0', FILTER_VALIDATE_INT);
$zero = filter_var ('0', FILTER_VALIDATE_INT);
$octal= filter_var ('-0123', FILTER_VALIDATE_INT);
var_dump ($positive);
var_dump ($negative);
var_dump ($zero);
var_dump ($octal);
?
--EXPECT--
int(0)
int(0)
int(0)
bool(false)
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/47752
--
Edit this bug report at http://bugs.php.net/?id=47752edit=1
#49442 [Opn]: Some queries crash PHP with mysqli_real_connect()
ID: 49442 Updated by: vr...@php.net Reported By: vr...@php.net Status: Open Bug Type: MySQLi related Operating System: Windows PHP Version: 5.3.0 New Comment: Backtrace analysis is available at http://www.vrana.cz/phpbug49442.zip Previous Comments: [2009-09-02 12:32:21] vr...@php.net Description: LOAD DATA LOCAL INFILE query together with connecting by mysqli_real_connect() causes PHP crash. Maybe it is not the single crashing query but common queries like SELECT or INSERT work. When I replace mysqli_init() + mysqli_real_connect() by mysqli_connect() then everything works (no crash). Reproduce code: --- ?php $dbh = mysqli_init(); $dbh-real_connect(, ODBC, , cds); $dbh-query(LOAD DATA LOCAL INFILE 'songs.csv' INTO TABLE songs); ? Expected result: Query executed OK. Actual result: -- PHP crashes. -- Edit this bug report at http://bugs.php.net/?id=49442edit=1
#49442 [Fbk]: Some queries crash PHP with mysqli_real_connect()
ID: 49442 Updated by: vr...@php.net Reported By: vr...@php.net Status: Feedback Bug Type: MySQLi related Operating System: Windows PHP Version: 5.3.0 New Comment: CREATE TABLE and sample CSV included in http://www.vrana.cz/phpbug49442.zip Previous Comments: [2009-09-02 13:21:23] paj...@php.net Please provide the create table and a small CSV to reproduce the problem. [2009-09-02 12:46:06] vr...@php.net Backtrace analysis is available at http://www.vrana.cz/phpbug49442.zip [2009-09-02 12:32:21] vr...@php.net Description: LOAD DATA LOCAL INFILE query together with connecting by mysqli_real_connect() causes PHP crash. Maybe it is not the single crashing query but common queries like SELECT or INSERT work. When I replace mysqli_init() + mysqli_real_connect() by mysqli_connect() then everything works (no crash). Reproduce code: --- ?php $dbh = mysqli_init(); $dbh-real_connect(, ODBC, , cds); $dbh-query(LOAD DATA LOCAL INFILE 'songs.csv' INTO TABLE songs); ? Expected result: Query executed OK. Actual result: -- PHP crashes. -- Edit this bug report at http://bugs.php.net/?id=49442edit=1
#49442 [Fbk-Opn]: Some queries crash PHP with mysqli_real_connect()
ID: 49442 Updated by: vr...@php.net Reported By: vr...@php.net -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: Windows PHP Version: 5.3.0 Previous Comments: [2009-09-02 13:27:42] vr...@php.net CREATE TABLE and sample CSV included in http://www.vrana.cz/phpbug49442.zip [2009-09-02 13:21:23] paj...@php.net Please provide the create table and a small CSV to reproduce the problem. [2009-09-02 12:46:06] vr...@php.net Backtrace analysis is available at http://www.vrana.cz/phpbug49442.zip [2009-09-02 12:32:21] vr...@php.net Description: LOAD DATA LOCAL INFILE query together with connecting by mysqli_real_connect() causes PHP crash. Maybe it is not the single crashing query but common queries like SELECT or INSERT work. When I replace mysqli_init() + mysqli_real_connect() by mysqli_connect() then everything works (no crash). Reproduce code: --- ?php $dbh = mysqli_init(); $dbh-real_connect(, ODBC, , cds); $dbh-query(LOAD DATA LOCAL INFILE 'songs.csv' INTO TABLE songs); ? Expected result: Query executed OK. Actual result: -- PHP crashes. -- Edit this bug report at http://bugs.php.net/?id=49442edit=1
#48912 [Opn]: Namespace causes unexpected strict behaviour
ID: 48912
Updated by: vr...@php.net
Reported By: david at grudl dot com
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 5.3.0
New Comment:
extract() uses ZEND_SEND_PREFER_REF. It seems that it is not compatible
with func_get_arg() under a namespace.
Previous Comments:
[2009-07-14 08:29:36] david at grudl dot com
Description:
The namespace clause causes the PHP behaves more strictly (unexpected
behavior according to the documentation - with regard to the namespaces
or function extract).
Reproduce code:
---
?php
// namespace A;
function test()
{
extract(func_get_arg(0));
}
test(array('x' = 1));
Expected result:
--none--
Actual result:
--
When row namespace A is commented:
--none--
When row namespace A is uncommented:
Strict Standards: Only variables should be passed by reference in ...
--
Edit this bug report at http://bugs.php.net/?id=48912edit=1
#44827 [Asn]: define('::') can be defined
ID: 44827
Updated by: vr...@php.net
Reported By: ka...@php.net
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-05)
Assigned To: iliaa
New Comment:
Code in ZendEngine2/zend_builtin_functions.c revision
1.277.2.12.2.25.2.52 checks if the class exists and creates the global
constant with the name A::B if it does. But this constant is unreachable
other than by get_defined_constants() because both constant(A::B) and
A::B works with class constants.
?php
class A {}
define(A::B, true);
echo constant(A::B); // Fatal error: Undefined class constant 'B'
echo A::B; // Fatal error: Undefined class constant 'B'
?
I suggest to issue an error if the constant name contains ::
regardless the class exists or not. The code would be even simpler.
Previous Comments:
[2009-06-08 13:10:06] tony2...@php.net
Reopened.
Patches for HEAD and 5_2 broke the build and have been reverted.
[2009-06-08 01:27:17] il...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-25 21:18:41] cel...@php.net
now that namespace separator will be \, the fix is simple: grep for
:: and fail if a user tries to do it.
[2008-04-25 10:11:39] ka...@php.net
As a note to this while we're at define().
define() also seems to ignore if you declare a class constant like:
define('test::c', 'test');
Both with and without having a class called 'test' passes this, testing
without the class 'test' like:
var_dump(test::c);
Will result in a fatal error: class 'test' not found. Testing it with a
class called 'test' will issue a fatal error: undefined class constant
'c'.
If the class 'test' already have a constant called 'c' define() will
still ignore it and var_dump() will return the real value of test::c.
[2008-04-25 10:01:38] ka...@php.net
Description:
PHP (5.2.5) allows you to define '::' as a constant without issuing an
E_WARNING, below examples will demonstrate it.
The constant() function will issue an fatal error when recieving '::'
as constant name:
Fatal error: Class '' not found in C:\webserver\www\gd\gd.php on line
91
Which might also be wrong or confusing to the programmer
Reproduce code:
---
?php
define('::', true);
var_dump(constant('::'));
?
Expected result:
A fatal error for each of the calls:
Fatal error: Invalid constant name in test.php on line 2
Fatal error: Invalid constant name in test.php on line 3
Actual result:
--
Fatal error: Class '' not found in C:\webserver\www\gd\gd.php on line
91
None warning or fatal error for define()...
--
Edit this bug report at http://bugs.php.net/?id=44827edit=1
#48314 [Fbk-Opn]: PDO_MySQL doesn't use prepared statements
ID: 48314 Updated by: vr...@php.net Reported By: vr...@php.net -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Windows PHP Version: 5.2.9 New Comment: Same result. Previous Comments: [2009-05-18 13:43:31] johan...@php.net Try also disabling PDO::ATTR_EMULATE_PREPARES. PHP 5.3 got some improvements/fixes with PDO_mysql (due to mysqlnd work) not sure if some parts can be backported. [2009-05-18 13:25:17] vr...@php.net Description: It seems that PDO_MySQL doesn't use prepared statements even with disabled PDO::MYSQL_ATTR_DIRECT_QUERY. If the prepared statements would by used then the binary data passed in the example wouldn't cause a parse error. MySQL version: 5.1.26 Reproduce code: --- ?php $pdo = new PDO(mysql:host=localhost, ODBC, ); $pdo-setAttribute(PDO::MYSQL_ATTR_DIRECT_QUERY, false); $pdo-exec(SET NAMES gbk); $stmt = $pdo-prepare(SELECT ?); $stmt-execute(array(chr(0xbf) . chr(0x27))); print_r($stmt-errorInfo()); ? Expected result: Array ( [0] = 0 ) Actual result: -- Array ( [0] = 42000 [1] = 1064 [2] = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''¿\''' at line 1 ) -- Edit this bug report at http://bugs.php.net/?id=48314edit=1
#47988 [Bgs]: php_phar.dll missing in distribution
ID: 47988 Updated by: vr...@php.net Reported By: vr...@php.net Status: Bogus Bug Type: PHAR related Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: All users are prompted to test PHP 5.3 before the release. For Windows users, there's no easy way to test PHP 5.3 with Phar if it is not a part of the archive. Previous Comments: [2009-04-17 12:55:45] paj...@php.net Statically built [2009-04-16 14:43:12] vr...@php.net Description: The PHAR extension is missing in the Windows versions of PHP 5.3.0RC1 and snapshots. -- Edit this bug report at http://bugs.php.net/?id=47988edit=1
#47988 [Bgs]: php_phar.dll missing in distribution
ID: 47988 Updated by: vr...@php.net Reported By: vr...@php.net Status: Bogus Bug Type: PHAR related Operating System: Windows PHP Version: 5.3 Assigned To: pajoye New Comment: I see, sorry. I've updated the docs at least. Previous Comments: [2009-04-17 13:05:03] paj...@php.net It is *builtin*. Run: php -m [2009-04-17 13:00:31] vr...@php.net All users are prompted to test PHP 5.3 before the release. For Windows users, there's no easy way to test PHP 5.3 with Phar if it is not a part of the archive. [2009-04-17 12:55:45] paj...@php.net Statically built [2009-04-16 14:43:12] vr...@php.net Description: The PHAR extension is missing in the Windows versions of PHP 5.3.0RC1 and snapshots. -- Edit this bug report at http://bugs.php.net/?id=47988edit=1
#47689 [Fbk-Opn]: crash with certain regular expression
ID: 47689 Updated by: vr...@php.net Reported By: vr...@php.net -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: Windows only PHP Version: * Assigned To: pajoye New Comment: Same result with VC9 TS and 500 lines under CLI. Previous Comments: [2009-04-10 17:43:42] paj...@php.net Please try using 5.3.0 VC9 snapshots(ts or NTS): http://windows.php.net [2009-04-10 15:15:15] nlop...@php.net this is the usual stack problem. Since we now use the stack for PCRE recursion on Windows, I think we could increase the stack size. The default (1 MB) is a little short.. Pierre: can you please increase the stack size on windows binaries to e.g. 8 MB? It's a matter of adding one parameter to the compile arguments. More details at: http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx [2009-03-19 10:22:04] vr...@php.net Both configuration directives are on the default value 10. I've found out that with much longer input (600 lines) the script crashes also in CLI. There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected. [2009-03-18 23:16:14] fel...@php.net Hi Jakub, please check the pcre.backtrack_limit and pcre.recursion_limit value. [2009-03-18 13:10:15] vr...@php.net I've uploaded the backtrace analysis to http://www.vrana.cz/phpbug47689.zip 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/47689 -- Edit this bug report at http://bugs.php.net/?id=47689edit=1
#47689 [Fbk-Opn]: crash with certain regular expression
ID: 47689 Updated by: vr...@php.net Reported By: vr...@php.net -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: Windows only PHP Version: * Assigned To: pajoye New Comment: Same result also with the code pasted here under Apache 2.2. Previous Comments: [2009-04-14 13:52:16] paj...@php.net Same result with VC9 TS and 500 lines under CLI. 500 lines? Not using the code you pasted here? [2009-04-14 13:42:20] vr...@php.net Same result with VC9 TS and 500 lines under CLI. [2009-04-10 17:43:42] paj...@php.net Please try using 5.3.0 VC9 snapshots(ts or NTS): http://windows.php.net [2009-04-10 15:15:15] nlop...@php.net this is the usual stack problem. Since we now use the stack for PCRE recursion on Windows, I think we could increase the stack size. The default (1 MB) is a little short.. Pierre: can you please increase the stack size on windows binaries to e.g. 8 MB? It's a matter of adding one parameter to the compile arguments. More details at: http://msdn.microsoft.com/en-us/library/tdkhxaks(VS.71).aspx [2009-03-19 10:22:04] vr...@php.net Both configuration directives are on the default value 10. I've found out that with much longer input (600 lines) the script crashes also in CLI. There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected. 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/47689 -- Edit this bug report at http://bugs.php.net/?id=47689edit=1
#47689 [Opn]: Apache crash with certain regular expression
ID: 47689
Updated by: vr...@php.net
Reported By: vr...@php.net
Status: Open
Bug Type: PCRE related
Operating System: Windows
PHP Version: 5.2.9-1
New Comment:
Both configuration directives are on the default value 10.
I've found out that with much longer input (600 lines) the script
crashes also in CLI.
There's no crash in PHP 5.2.8, only PHP 5.2.9 is affected.
Previous Comments:
[2009-03-18 23:16:14] fel...@php.net
Hi Jakub,
please check the pcre.backtrack_limit and pcre.recursion_limit value.
[2009-03-18 13:10:15] vr...@php.net
I've uploaded the backtrace analysis to
http://www.vrana.cz/phpbug47689.zip
[2009-03-17 16:18:51] il...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2009-03-17 13:57:03] vr...@php.net
Description:
Apache 2.2.11 crashes with PHP 5.2.9-1 on the following code. The same
script run from CLI executes without crash.
Reproduce code:
---
?php
$contents = '/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/';
// shortest possible example, omitting last line causes no crash
$contents = preg_replace('@/\\*(?:.|[\\n\\r])*?\\*/@', '', $contents);
?
Expected result:
Empty string in $contents.
Actual result:
--
Apache crash.
--
Edit this bug report at http://bugs.php.net/?id=47689edit=1
#47689 [Fbk-Opn]: Apache crash with certain regular expression
ID: 47689
Updated by: vr...@php.net
Reported By: vr...@php.net
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Windows
PHP Version: 5.2.9-1
New Comment:
I've uploaded the backtrace analysis to
http://www.vrana.cz/phpbug47689.zip
Previous Comments:
[2009-03-17 16:18:51] il...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2009-03-17 13:57:03] vr...@php.net
Description:
Apache 2.2.11 crashes with PHP 5.2.9-1 on the following code. The same
script run from CLI executes without crash.
Reproduce code:
---
?php
$contents = '/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* License); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing,
* software distributed under the License is distributed on an
* AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
* KIND, either express or implied. See the License for the
* specific language governing permissions and limitations
* under the License.
*/';
// shortest possible example, omitting last line causes no crash
$contents = preg_replace('@/\\*(?:.|[\\n\\r])*?\\*/@', '', $contents);
?
Expected result:
Empty string in $contents.
Actual result:
--
Apache crash.
--
Edit this bug report at http://bugs.php.net/?id=47689edit=1
#47050 [Bgs-Opn]: mysqli_poll() modifies improper variables
ID: 47050 Updated by: vr...@php.net Reported By: vr...@php.net -Status: Bogus +Status: Open Bug Type: MySQLi related Operating System: Windows PHP Version: 5.3.0alpha4-dev New Comment: The modification of $links is not the problem, it works as expected. The problem is in modification of $all_links which was not passed to mysqli_poll() at all. Previous Comments: [2009-01-11 00:14:41] fel...@php.net It's looks expected, Jakub. See the prototype: public int mysqli::poll ( array $read , array $error , array $reject , int $sec [, int $usec ] ) int mysqli_poll ( array $read , array $error , array $reject , int $sec [, int $usec ] ) [2009-01-09 13:06:50] vr...@php.net Description: mysqli_poll() modifies the variable which was assigned to variables passed to mysqli_poll(). The reason probably is that mysqli_poll() doesn't copy zvals on write as it should. Reproduce code: --- ?php $link1 = mysqli_connect(); $link1-query(SELECT 'test', MYSQLI_ASYNC); $all_links = array($link1); $links = $errors = $reject = $all_links; mysqli_poll($links, $errors, $reject, 1); print_r($all_links); Expected result: Array ( [0] = mysqli Object ) Actual result: -- Array ( ) -- Edit this bug report at http://bugs.php.net/?id=47050edit=1
#43779 [Csd-Opn]: ldap_explode_dn returns superfluous count
ID: 43779
Updated by: [EMAIL PROTECTED]
-Summary: ldap_explode_dn returns undocumented values
Reported By: gabe at mudbugmedia dot com
-Status: Closed
+Status: Open
-Bug Type:Documentation problem
+Bug Type:LDAP related
-PHP Version: Irrelevant
+PHP Version: 5.2.6
New Comment:
The count element is unnecessary as PHP has count() function.
Previous Comments:
[2008-11-07 14:08:40] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
The first element in this array has count key and represents the
number of returned values, next elements are numerically indexed DN
components.
[2008-01-07 20:50:38] gabe at mudbugmedia dot com
Description:
The documentation for ldap_explode_dn says that the return value should
be Returns an array of all DN components.. Not only is this vague (a
separate problem), it fails to document that the returned array is an
associative array where the first key/value being 'count' = (integer),
where the count is the total number of elements in the array.
Reproduce code:
---
$dn=cn=example,dc=example,dc=com;
var_dump(ldap_explode_dn($dn,0));
Expected result:
array(3) {
[0]=
string(19) cn=example
[1]=
string(19) dc=example
[2]=
string(4) dc=com
}
Actual result:
--
array(3) {
[count]=
int(3)
[0]=
string(19) cn=example
[1]=
string(19) dc=example
[2]=
string(4) dc=com
}
--
Edit this bug report at http://bugs.php.net/?id=43779edit=1
#45927 [Opn]: man page spelling errors, misused minus signs, and bad whatis entriewds
ID: 45927 Updated by: [EMAIL PROTECTED] Reported By: atomo64 at gmail dot com Status: Open -Bug Type:Documentation problem +Bug Type:Scripting Engine problem -PHP Version: Irrelevant +PHP Version: 5.2.6 New Comment: Manual pages are part of the source code. Previous Comments: [2008-08-26 17:48:54] atomo64 at gmail dot com Description: sapi/cli/php.1.in, scripts/man1/php-config.1.in, and scripts/man1/phpize.1.in all have bad whatis entries (i.e. whatis man page name won't display the whatis information from the man page). And there are a couple of typos and misused minus signs in sapi/cli/php.1.in The patch for the first issue can be found at: http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/bad_whatis_entries.patch?rev=1127view=markup And the other patch for the second issue can be found at: http://svn.debian.org/viewsvn/pkg-php/php5/trunk/debian/patches/manpage_spelling.patch?rev=1038view=markup -- Edit this bug report at http://bugs.php.net/?id=45927edit=1
#45283 [Opn]: extract($_FILES) result unpredictable
ID: 45283
Updated by: [EMAIL PROTECTED]
Reported By: php at info-svc dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.6
New Comment:
Results of extract() shouldn't depend on register_globals.
Previous Comments:
[2008-07-02 12:26:50] [EMAIL PROTECTED]
It's documentation issue. Plus you really should NOT be using
register_globals=On. And using extract() on $_FILES...well..that's very
flaky idea to begin with. Just don't do it. :)
[2008-06-19 04:59:15] php at info-svc dot com
I confirmed this behavior with PHP 5.2.6 running on IIS and Windows
2003 SP2.
Test case output with register_globals Off
array(5) {
[name]=
string(14) samplefile.txt
[type]=
string(10) text/plain
[tmp_name]=
string(25) C:\WINDOWS\Temp\php57.tmp
[error]=
int(0)
[size]=
int(459)
}
string(25) C:\WINDOWS\Temp\php57.tmp
Test case output with register_globals On
string(25) C:\WINDOWS\Temp\php58.tmp
string(1) C
So I'm convinced that register_globals is involved here. There is
something horribly wrong with this feature or its documentation.
[2008-06-16 18:09:31] php at info-svc dot com
Adding to the confusion, I thought perhaps the unexpected behavior
could be caused by the register_globals configuration. However,
according to documentation ...
http://www.php.net/manual/en/faq.misc.php#faq.misc.registerglobals
... extract($_FILES, EXTR_SKIP); is the correct way to emulate
register_globals On. I dumped all of the other superglobals and
confirmed the only one containing a 'themefile' index was $_FILES. Both
var_dump($_POST); and var_dump($_GET); returned array(0) {}
[2008-06-16 17:39:59] php at info-svc dot com
Note about the Reproduce code, for best results use
form method=POST enctype=multipart/form-data
[2008-06-16 17:20:28] php at info-svc dot com
Description:
After receiving reports of a broken feature, the problem was traced to
extract($_FILES) producing different results on different servers.
A server running PHP 5.2.5 gave the expected result where
$variable['tmp_name'] contained the uploaded file path. A server
running PHP 5.2.3 gave the unexpected result where $variable['tmp_name']
always dumped as string(1) /
The workaround is to use $_FILES['tmp_name'] in which case both servers
gave the expected result.
I am stumped as to whether this is caused by a bug that was fixed
between versions or some configuration issue I am not aware of?
Robert Chapin
Chapin Information Services, Inc.
Reproduce code:
---
form method=POST
input name=themefile type=file /
input type=submit /
/form
?php
extract($_FILES, EXTR_SKIP);
var_dump($themefile);
var_dump($themefile['tmp_name']);
?
Expected result:
array(5) {
[name]=
string(20) samplefile.txt
[type]=
string(24) application/octet-stream
[tmp_name]=
string(18) /var/tmp/phpSJkwr0
[error]=
int(0)
[size]=
int(379)
}
string(18) /var/tmp/phpSJkwr0
Actual result:
--
string(14) /tmp/phpZOtyB7
string(1) /
--
Edit this bug report at http://bugs.php.net/?id=45283edit=1
#40248 [Opn]: Undefined members with combined operators produce no warning
ID: 40248 Updated by: [EMAIL PROTECTED] Reported By: jontsa at amigaone dot cc Status: Open -Bug Type: Documentation problem +Bug Type: Class/Object related Operating System: Solaris PHP Version: 5.2.0 New Comment: I gave two reasons why this is a bug: 1. Consistency 1a. $b-a += 5 should be semantic equivalent to $b-a = $b-a + 5. Later produces notice, former not. 1b. Both $a += 5 and $a = $a + 5 produces notice (same for arrays). Object properties miss one notice. 2. Error-prone The notice is here to inform the programmer about working with undefined variable/property/index. Adding a value to a property is clearly a usage of the property. Jani gave one reason (operator precedence) which is erroneous because $b-a alone issues the notice too. Discussed on internals: http://news.php.net/php.internals/31732 Before bogusing this report again please provide some real arguments on [EMAIL PROTECTED] Previous Comments: [2007-08-19 20:12:24] [EMAIL PROTECTED] *sigh* If you don't want to document it, let someone else document it. This is _NOT_ any bug. [2007-08-18 08:26:19] [EMAIL PROTECTED] ?php $c = $c + 5; // Notice $a += 5; // Notice $b = new stdClass; $b-a; // Notice $b-c = $b-c + 5; // Notice $b-a += 5; ? It really is not a rocket science. This behavior is inconsistent and errors-hiding. The explanation through operator precedence doesn't work as $b-a alone issues the notice too. If you don't want to fix it then leave it to others. [2007-08-17 23:34:16] [EMAIL PROTECTED] Operator precedence. $b-a happens before += and thus the property does exist before assignment. Not really rocket science. Now go document it. [2007-08-17 16:05:48] [EMAIL PROTECTED] If this incostitent and possibly-errors-hiding behavior should be documented as a feature it should be explained why PHP behaves this way. Please write down the reasons why this is the correct behavior. I provided two reasons why this is more bug than a feature. [2007-08-17 13:37:23] [EMAIL PROTECTED] Because it is. 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/40248 -- Edit this bug report at http://bugs.php.net/?id=40248edit=1
#37273 [Opn]: Symlinks and session handler allow open_basedir bypass
ID: 37273 Updated by: [EMAIL PROTECTED] Reported By: c dot i dot morris at durham dot ac dot uk Status: Open -Bug Type: Documentation problem +Bug Type: Session related Operating System: Linux PHP Version: 5.1.3 New Comment: Security vulnerability should be better fixed in source than documented. Previous Comments: [2006-07-27 11:41:42] a dot d dot stribblehill at durham dot ac dot uk This is *not* a documentation bug: as the original report says, it is a security vulnerability -- one that can and should be fixed in the code. [2006-07-27 01:34:11] [EMAIL PROTECTED] Reclassified. Ilia will give more info for whomever is going to document this. [2006-06-16 14:32:37] c dot i dot morris at durham dot ac dot uk For a possible solution to this, in ext/session/mod_files.c, the ps_files_open function has: data-fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR | O_BINARY, data-filemode); On systems that support O_NOFOLLOW (FreeBSD, Linux=2.2, maybe others) you can probably do data-fd = VCWD_OPEN_MODE(buf, O_CREAT | O_RDWR | O_BINARY | O_NOFOLLOW, data-filemode); which will cause this open to fail (with error ELOOP) if the session file is a symlink rather than a regular file. On systems that don't support O_NOFOLLOW, stat()ing the file and making sure the file mode isn't S_IFLNK should do it. Would you like me to try to put together a patch for this? [2006-05-03 16:19:05] c dot i dot morris at durham dot ac dot uk As above - I managed to lose the bug password and it took a while to come through to my email. [2006-05-03 13:30:53] cim at compsoc dot dur dot ac dot uk Ah, there appears to be some confusion over what I mean. I don't mean ini_set() the session directory to a symlink, I mean set the session directory to a real directory (which, yes, must be within open_basedir confines) that contains a symlink outside open_basedir. (So, for example, open_basedir = /users/www1/, create a symlink from /users/www1/bob/sess_abc to /users/www2/fred/target, ini_set() the session storage directory to /users/www1/bob/, and then create a session with ID 'abc' using ?PHPSESSID=abc) Does that make more sense? 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/37273 -- Edit this bug report at http://bugs.php.net/?id=37273edit=1
#37047 [Ver-Opn]: static executes after return
ID: 37047
Updated by: [EMAIL PROTECTED]
Reported By: karoly at negyesi dot net
-Status: Verified
+Status: Open
-Bug Type: Documentation problem
+Bug Type: Variables related
Operating System: Irrevelant
PHP Version: 5.1.2
New Comment:
If static variables are resolved in compile time then
?php
function storage($key) {
return $storage;
static $storage = array('a' = array('x', 'y'));
}
var_dump(storage('a'));
?
should give an expected result.
Previous Comments:
[2006-04-12 08:31:01] [EMAIL PROTECTED]
It's the same as
?php
exit;
class Test { }
?
The class will be still declared, even though there is an exit
statement before the declaration. It doesn't mean that it's executed,
because there is a big difference between execution and compilation.
[2006-04-11 22:44:27] karoly at negyesi dot net
Hint. If you doc this please doc everything as well that executes at
compile time. It will be a very interesting handbook page...
[2006-04-11 22:38:31] [EMAIL PROTECTED]
Sorry. I misread.
You're right (-:
S
[2006-04-11 22:37:29] [EMAIL PROTECTED]
see: http://php.net/return
the return() statement immediately ends execution of the current
function
(It's already documented.)
S
[2006-04-11 22:28:04] karoly at negyesi dot net
Then this is a docs issue. Because I do not expect anything to be
executed after a return...
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/37047
--
Edit this bug report at http://bugs.php.net/?id=37047edit=1
#35936 [Ver-Opn]: ini.zlib.output-compression Documentation
ID: 35936 Updated by: [EMAIL PROTECTED] Reported By: sBoisvert at bryxal dot ca -Status: Verified +Status: Open -Bug Type: Documentation problem +Bug Type: Zlib Related Operating System: XP PHP Version: 5.1.1 New Comment: Is there a reason to not be able to *enable* the output compression from runtime? Previous Comments: [2006-05-24 11:48:54] [EMAIL PROTECTED] IIRC (and reading the code reveals that) it's possible to *disable* zlib.output_compression at runtime, which actually works fine here. [2006-04-15 21:29:36] [EMAIL PROTECTED] Looks like the docs are wrong and this option is actually not PHP_INI_ALL, but PHP_INI_SYSTEM|PHP_INI_PERDIR. This was accidentally changed with this patch: http://cvs.php.net/viewcvs.cgi/php-src/ext/zlib/zlib.c?r1=1.136r2=1.137 [2006-01-09 15:00:46] [EMAIL PROTECTED] php_enable_output_compression() is called only in PHP_RINIT_FUNCTION() and not in OnUpdate_zlib_output_compression(). [2006-01-09 01:17:56] sBoisvert at bryxal dot ca Description: This has either not been fixed or crept back in. (Bug #17299) The documentation on http://ca3.php.net/manual/en/ref.zlib.php#ini.zlib.output-compression it states zlib.output_compression boolean/integer In runtime, it can be set only before sending any output. but any attempts to set ini_set(zlib.output_compression, on); ini_set(zlib.output_compression_level, 5); will NOT compress data before sending it. Either this is a bug that slipped in lately or a documentation problem. A comment has already been left by someone on this page commenting on his inability to make this work. Thank you Reproduce code: --- ini_set(zlib.output_compression, on); ini_set(zlib.output_compression_level, 5); echo(ini_get(zlib.output_compression)); Expected result: compressed: on Actual result: -- uncompressed: on -- Edit this bug report at http://bugs.php.net/?id=35936edit=1
#40248 [Opn]: Undefined members with combined operators produce no warning
ID: 40248 Updated by: [EMAIL PROTECTED] Reported By: jontsa at amigaone dot cc Status: Open -Bug Type: Documentation problem +Bug Type: Class/Object related Operating System: Solaris PHP Version: 5.2.0 New Comment: ?php $c = $c + 5; // Notice $a += 5; // Notice $b = new stdClass; $b-a; // Notice $b-c = $b-c + 5; // Notice $b-a += 5; ? It really is not a rocket science. This behavior is inconsistent and errors-hiding. The explanation through operator precedence doesn't work as $b-a alone issues the notice too. If you don't want to fix it then leave it to others. Previous Comments: [2007-08-17 23:34:16] [EMAIL PROTECTED] Operator precedence. $b-a happens before += and thus the property does exist before assignment. Not really rocket science. Now go document it. [2007-08-17 16:05:48] [EMAIL PROTECTED] If this incostitent and possibly-errors-hiding behavior should be documented as a feature it should be explained why PHP behaves this way. Please write down the reasons why this is the correct behavior. I provided two reasons why this is more bug than a feature. [2007-08-17 13:37:23] [EMAIL PROTECTED] Because it is. [2007-08-17 11:09:21] [EMAIL PROTECTED] Why this form of usage of undefined property should be considered as feature? [2007-05-10 20:40:29] [EMAIL PROTECTED] This is actually a feature. Can't seem to find where it's documented though so reclassifying. 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/40248 -- Edit this bug report at http://bugs.php.net/?id=40248edit=1
#40248 [Opn]: Undefined members with combined operators produce no warning
ID: 40248 Updated by: [EMAIL PROTECTED] Reported By: jontsa at amigaone dot cc Status: Open -Bug Type: Documentation problem +Bug Type: Class/Object related Operating System: Solaris PHP Version: 5.2.0 New Comment: Why this form of usage of undefined property should be considered as feature? Previous Comments: [2007-05-10 20:40:29] [EMAIL PROTECTED] This is actually a feature. Can't seem to find where it's documented though so reclassifying. [2007-01-26 10:12:51] jontsa at amigaone dot cc Description: When using a combined operator like += or ++ on an undefined class member, it does not produce undefined property notice as expected. Tested with all errors enabled. Reproduce code: --- $a+=5; $b=new stdClass; $b-a+=5; Expected result: Notice: Undefined variable: a Notice: Undefined property: stdClass::$a Actual result: -- Notice: Undefined variable: a -- Edit this bug report at http://bugs.php.net/?id=40248edit=1
#39565 [Opn]: xmlparser and accentuated letters
ID: 39565
Updated by: [EMAIL PROTECTED]
Reported By: sotiwin at freemail dot hu
Status: Open
-Bug Type: Documentation problem
+Bug Type: XML related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
This behavior is wrong - all character data should be passed at once.
Previous Comments:
[2006-11-21 12:27:15] sotiwin at freemail dot hu
Really? How could I parse an xml with accented data? Can I get the
whole word in one piece?
[2006-11-21 08:17:08] [EMAIL PROTECTED]
This is expected behavior, although we should definitely document this
in a bit better way - changing it to a documentation problem.
[2006-11-21 02:16:31] sotiwin at freemail dot hu
Description:
I want to parse an xml, with accentuated letters, but the parser cuts
the characters before the first accentuated letter of each
'characterData'.
I use Wamp5 with php 5.1.6.
Reproduce code:
---
meta http-equiv=Content-type value=text/html; charset=ISO-8859-1
/
?php
function characterData($parser, $data)
{
echo $data.'1';
}
$data='?xml version=1.0
encoding=ISO-8859-1?bookExampleéá/book';
echo 'XML input:br'.$data;
$xml_parser = xml_parser_create('ISO-8859-1');
xml_parser_set_option($xml_parser,XML_OPTION_SKIP_WHITE,1);
xml_set_character_data_handler($xml_parser,'characterData');
echo 'brParsed data:br';
if (!xml_parse($xml_parser, $data))
{
die(sprintf(XML error: %s at line %d,
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
xml_parser_free($xml_parser);
?
Expected result:
characterData could have run only once.
XML input:
Exampleéá
Parsed data:
Exampleéá1
Actual result:
--
characterData could have runs twice.
XML input:
Exampleéá
Parsed data:
Example1éá1
--
Edit this bug report at http://bugs.php.net/?id=39565edit=1
#39356 [Ana-Csd]: in_array() causes Nesting level too deep fatal error
ID: 39356
Updated by: [EMAIL PROTECTED]
Reported By: 7am dot online at gmail dot com
-Status: Analyzed
+Status: Closed
-Bug Type: Documentation problem
+Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.2.0
Previous Comments:
[2007-06-15 05:35:31] judas dot iscariote at gmail dot com
This behaviour has been corrected in current 5_2 CVS, if now first try
with === on objects and then with == effectively helping to avoid the
recursive dependency in **some** cases like the test case of the
reporter.
[2006-11-23 18:24:01] ken at smallboxsoftware dot net
I am experiencing this issue as well. Seems like a fairly large change
not to document. Also == can no longer be used to compare objects of
this configuration while === still can. Perhaps the functionality
behind === could be used in the in_array function when comparing
objects?
[2006-11-04 14:47:26] [EMAIL PROTECTED]
http://php.net/in_array is completely quiet about references
this is a change from 5.1 so it should at least be a documentation
problem.
[2006-11-03 14:01:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
In php 5 objects are passed by reference, so your code does in
fact create a circular dependency.
[2006-11-03 03:04:24] 7am dot online at gmail dot com
Description:
Doing a in_array() check against an array containing objects with
recursive dependency causes a Nesting level too deep - recursive
dependency? fatal error.
Reproduce code:
---
?php
class A
{
public $b;
}
class B
{
public $a;
}
$a = new A;
$b = new B;
$b-a = $a;
$a-b = $b;
$test = array($a, $b);
var_dump(in_array($a, $test));
Expected result:
bool(true), as in PHP5.1.6
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
[FILENAME] on line 19
--
Edit this bug report at http://bugs.php.net/?id=39356edit=1
#39070 [Opn]: debug_backtrace output when call_user_func or error handler involved
ID: 39070
Updated by: [EMAIL PROTECTED]
Reported By: alan dot harder at sun dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: Feature/Change Request
Operating System: *
-PHP Version: Irrelevant
+PHP Version: 5.2.0
New Comment:
Both PHP 4 and PHP 5 can be improved:
PHP 5 should fill file and line as PHP 4 do.
PHP 4 should list 'my_func' only once as PHP 5 do.
Previous Comments:
[2006-10-06 20:16:51] alan dot harder at sun dot com
Description:
I have found some inconsistencies in the behavior of debug_backtrace.
I'm not sure either of these are bugs, so I'm filing this under
documentation.
1) If call_user_func is used, debug_backtrace output includes an array
entry with no file/line info. Seems to be the case with PHP versions as
far back as 4.3.0.
debug_backtrace docs do say these are the possible values to be in
the backtrace, but doesn't list any conditions where file/line might be
omitted. If this behavior in the debug_backtrace output is expected,
then maybe document this here.
2) If an error handler is invoked, debug_backtrace output differs
between PHP versions. PHP 4.x has 2 entries (one with error handler and
its params, another with file/line where error occurred).. PHP 5.1.x and
5.2.0RC5 combine these into a single entry (didn't text 5.0.x). Maybe
this is related, not sure: http://bugs.php.net/bug.php?id=34175
Perhaps this should be a ChangeLog entry on the docs page for
debug_backtrace.
Reproduce code:
---
pre?php
function my_func() { 1 / 0; }
function do_backtrace() { print_r(debug_backtrace()); }
set_error_handler('do_backtrace');
call_user_func('my_func');
?/pre
Expected result:
Output that can be predicted by reading the debug_backtrace docs.
Actual result:
--
file/line missing for entry after call_user_func, and array length
differs between PHP 4.x and 5.1.x/5.2.0.
--
Edit this bug report at http://bugs.php.net/?id=39070edit=1
#39065 [Opn]: undocumented: symlink() changes behaviour depending on ZTS
ID: 39065 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at triphoenix dot de Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: Unix -PHP Version: Irrelevant +PHP Version: 5.2.2 New Comment: It should behave same. Previous Comments: [2007-05-10 16:32:26] brunofr at ioda dot net Same issue pb sur php 5.2.2 [2006-10-06 14:39:44] phpbugs at triphoenix dot de Description: The symlink() function changes its behaviour depending on the ZTS define. If ZTS is not defined, all are created relative, if ZTS is enabled, the parameters are evaluated to actual absolute directories and thus are created absolute. This is different behaviour and should be at least documented in a proper way. Reproduce code: --- symlink(.., testlink); Expected result: Depending on enabled or disabled ZTS the symlink will be created relative (pointing to ..) or absolute (e.g. if currently in /tmp/test/phptest pointing to /tmp/test). If the link (or the directory containing it) is being moved/renamed later, the latter can lead to a broken link while the first cannot. -- Edit this bug report at http://bugs.php.net/?id=39065edit=1
#39565 [Opn]: xmlparser and accentuated letters
ID: 39565
Updated by: [EMAIL PROTECTED]
Reported By: sotiwin at freemail dot hu
Status: Open
-Bug Type: Documentation problem
+Bug Type: XML related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
Fortunately it wouldn't break BC.
If you want to put the whole string to one item you need to concatenate
it currently. If the whole string would be returned at once there's
nothing to concatenate so the result is the same.
Previous Comments:
[2007-08-17 13:31:58] [EMAIL PROTECTED]
If it was changed we'd break BC. Documentation issue.
[2007-08-17 11:53:35] [EMAIL PROTECTED]
This behavior is wrong - all character data should be passed at once.
[2006-11-21 12:27:15] sotiwin at freemail dot hu
Really? How could I parse an xml with accented data? Can I get the
whole word in one piece?
[2006-11-21 08:17:08] [EMAIL PROTECTED]
This is expected behavior, although we should definitely document this
in a bit better way - changing it to a documentation problem.
[2006-11-21 02:16:31] sotiwin at freemail dot hu
Description:
I want to parse an xml, with accentuated letters, but the parser cuts
the characters before the first accentuated letter of each
'characterData'.
I use Wamp5 with php 5.1.6.
Reproduce code:
---
meta http-equiv=Content-type value=text/html; charset=ISO-8859-1
/
?php
function characterData($parser, $data)
{
echo $data.'1';
}
$data='?xml version=1.0
encoding=ISO-8859-1?bookExampleéá/book';
echo 'XML input:br'.$data;
$xml_parser = xml_parser_create('ISO-8859-1');
xml_parser_set_option($xml_parser,XML_OPTION_SKIP_WHITE,1);
xml_set_character_data_handler($xml_parser,'characterData');
echo 'brParsed data:br';
if (!xml_parse($xml_parser, $data))
{
die(sprintf(XML error: %s at line %d,
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
xml_parser_free($xml_parser);
?
Expected result:
characterData could have run only once.
XML input:
Exampleéá
Parsed data:
Exampleéá1
Actual result:
--
characterData could have runs twice.
XML input:
Exampleéá
Parsed data:
Example1éá1
--
Edit this bug report at http://bugs.php.net/?id=39565edit=1
#40248 [Opn]: Undefined members with combined operators produce no warning
ID: 40248 Updated by: [EMAIL PROTECTED] Reported By: jontsa at amigaone dot cc Status: Open -Bug Type: Documentation problem +Bug Type: Class/Object related Operating System: Solaris PHP Version: 5.2.0 New Comment: If this incostitent and possibly-errors-hiding behavior should be documented as a feature it should be explained why PHP behaves this way. Please write down the reasons why this is the correct behavior. I provided two reasons why this is more bug than a feature. Previous Comments: [2007-08-17 13:37:23] [EMAIL PROTECTED] Because it is. [2007-08-17 11:09:21] [EMAIL PROTECTED] Why this form of usage of undefined property should be considered as feature? [2007-05-10 20:40:29] [EMAIL PROTECTED] This is actually a feature. Can't seem to find where it's documented though so reclassifying. [2007-01-26 10:12:51] jontsa at amigaone dot cc Description: When using a combined operator like += or ++ on an undefined class member, it does not produce undefined property notice as expected. Tested with all errors enabled. Reproduce code: --- $a+=5; $b=new stdClass; $b-a+=5; Expected result: Notice: Undefined variable: a Notice: Undefined property: stdClass::$a Actual result: -- Notice: Undefined variable: a -- Edit this bug report at http://bugs.php.net/?id=40248edit=1
#41946 [Opn]: Minor detail missing in documentation.
ID: 41946 Updated by: [EMAIL PROTECTED] Reported By: youare at loss4words dot com Status: Open -Bug Type: Documentation problem +Bug Type: Network related Operating System: Debian 4.0 PHP Version: 5.1 New Comment: ip2long should return -1 only for 255.255.255.255. Empty string should result in FALSE. Previous Comments: [2007-07-11 01:35:07] youare at loss4words dot com Err, somehow it dropped my version out of the textfield through successive CAPTCHAs and reloads. Anyway I'm using 5.1. [2007-07-10 07:19:00] youare at loss4words dot com Description: Documentation for ip2long needs a little more detail. It says that it returns FALSE if the argument passed is not a valid IP address, and says this returned -1 before version 5. It should also mention that if it is passed an empty argument that it will still return -1. Reproduce code: --- ?php echo br /Result: . ip2long(10.10.10.10); // returns long echo br /Result: . ip2long(not.an.ip.address); // returns FALSE echo br /Result: . ip2long(); // should return FALSE, returns -1 ? Expected result: Result: 168430090 Result: Result: Actual result: -- Result: 168430090 Result: Result: -1 -- Edit this bug report at http://bugs.php.net/?id=41946edit=1
#41662 [Opn]: SimpleXML-children() misleading result
ID: 41662 Updated by: [EMAIL PROTECTED] Reported By: kenashkov at gmail dot com Status: Open -Bug Type: Documentation problem +Bug Type: SimpleXML related Operating System: Fedora Core 4 PHP Version: 5.2.3 New Comment: There's no reason why a node without subnode should return anything in its children(). Especially if there is attributes() method returning attributes. Please fix the sources. Previous Comments: [2007-06-12 07:36:50] kenashkov at gmail dot com Description: Testing an SimpleXMLElement object for children is unconsistent. Here is an example: $str = 'rootnodesubnode/subnode/rootnode'; $x = new SimpleXMLElement($str); if($x-subnode-children()) print 'yes'; else print 'no'; - will print 'no'; If the $str='rootnodesubnodenewnode/newnode/subnode/rootnode'; it will print yes. But the same will happen if the subnode has an attribute like: $str = 'rootnodesubnode id=2/subnode/rootnode'; But if we use foreach($x-subnode-children() as $key=$value) in the latter example we will not get anything (which is correct). I think is wrong the children() method to return object when there are no child objects and the node has attributes (because for querying the attributes we have the attributes() method). This was discussed in php-dev list - http://marc.info/?l=php-devm=118001203709813w=2 If this is not a bug, I think a note regarding this behaviour must be added in the docs. Reproduce code: --- $str = 'rootnodesubnode id=2/subnode/rootnode'; $x = new SimpleXMLElement($str); if($x-subnode-children()) print 'yes'; else print 'no'; Expected result: no Actual result: -- yes -- Edit this bug report at http://bugs.php.net/?id=41662edit=1
#41904 [Opn]: proc_open with empty array as $env uses $_ENV of parent
ID: 41904
Updated by: [EMAIL PROTECTED]
Reported By: martin dot partel at mbnet dot fi
Status: Open
-Bug Type: Documentation problem
+Bug Type: Program Execution
Operating System: Linux
PHP Version: 5.2.3
New Comment:
Empty array should pass empty environment to be able to pass this
special value.
Previous Comments:
[2007-07-05 13:51:44] [EMAIL PROTECTED]
Reclassified as docu issue.
[2007-07-05 13:35:01] martin dot partel at mbnet dot fi
Description:
The documentation of proc_open states that passing NULL as the $env
parameter of proc_open has the child process use the same
environment as the current PHP process. Passing an empty array seems
to have the same effect, even though intuitively it should give the
child process an empty environment.
Reproduce code:
---
?php
echo 'pre';
$descriptorspec = array(
0 = array(pipe, r),
1 = array(pipe, w),
);
$cwd = '/tmp';
$env = array();
$process = proc_open('php', $descriptorspec, $pipes, $cwd, $env);
if (is_resource($process)) {
fwrite($pipes[0], '?php print_r($_ENV); ?');
fclose($pipes[0]);
echo stream_get_contents($pipes[1]);
fclose($pipes[1]);
proc_close($process);
}
Expected result:
The script should output an (almost) empty $_ENV.
Actual result:
--
The script outputs the $_ENV of the parent process.
--
Edit this bug report at http://bugs.php.net/?id=41904edit=1
#40740 [Opn]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at filofox dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: PDO related
Operating System: Linux Debian Sarge 3.1
PHP Version: 5.2.1
New Comment:
Emulation is wrong if it doesn't work. Numbers after LIMIT should not
be quoted.
Previous Comments:
[2007-03-07 09:54:18] [EMAIL PROTECTED]
Use PDO::ATTR_EMULATE_PREPARES = false to turn off emulation of
prepared statements.
PDO_MYSQL uses it by default because native prepared statements in
MySQL are quite limited - you can't use SHOW statements, for example.
The documentation should mention it, though.
Reclassified as docu problem.
[2007-03-06 17:13:44] phpbugs at filofox dot com
Description:
The following emerged after upgrading from 5.2.0 to 5.2.1 and has been
checked in both versions: the error only occurs in 5.2.1 .
When passing parameters into a LIMIT clause using PDO::execute(), it
appears that PDO is quoting the parameters, which causes MYSQL to throw
an error.
FYI: PDO_MYSQL is built against MySQL client library 5.0.18.
Reproduce code:
---
$dbh = new PDO('mysql:localhost;dbname=my_db', 'user', '' );
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try{
$query = $dbh-prepare( 'SELECT * FROM some_table LIMIT :start,
:limit' );
if ( $query-execute ( array ( 'start' = 0, 'limit' = 10 ) ) )
{
while ( $row = $query-fetch ( PDO::FETCH_ASSOC ) )
{
print_r($row);
}
$query-closeCursor();
}
} catch( Exception $e ){
print_r( $e );
}
Expected result:
A number of rows are returned.
Actual result:
--
An exception is thrown:
PDOException Object
(
[message:protected] = SQLSTATE[42000]: Syntax error or access
violation: 1064 You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to
use near ''0', '10'' at line 1
[string:private] =
[code:protected] = 42000
[file:protected] = [my_file].php
[line:protected] = 19
[trace:private] = Array
(
[0] = Array
(
[file] = [my_file].php
[line] = 19
[function] = execute
[class] = PDOStatement
[type] = -
[args] = Array
(
[0] = Array
(
[start] = 0
[limit] = 10
)
)
)
)
[errorInfo] = Array
(
[0] = 42000
[1] = 1064
[2] = You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near ''0', '10'' at line 1
)
)
--
Edit this bug report at http://bugs.php.net/?id=40740edit=1
#40586 [Opn]: _ENV vars get espcaped when magic_quotes_gpc is on
ID: 40586 Updated by: [EMAIL PROTECTED] Reported By: gk at gknw dot de Status: Open -Bug Type: Documentation problem +Bug Type: Strings related Operating System: at least NetWare, Win32 -PHP Version: Irrelevant +PHP Version: 4.4.x New Comment: This behavior is wrong. _gpc stands for GET, POST, COOKIE. Previous Comments: [2007-02-21 20:30:40] gk at gknw dot de Description: With PHP 4.3.x and 4.4.x the _ENV superglobals get escaped if they contain backslahes and magic_quotes_gpc is on. This does happen with the Apache SAPI as well as with the CLI on commandline. When I getenv() same environment vars this doesnt happen. Also compared to PHP 5.2.x where this doesnt happen - regardless of the magic_quotes_gpc setting. I digged through the docu but couldnt find anything about this 'feature' mentioned with 4.x, nor the difference that it was dropped with 5.x. Expected result: I think this 'feature' should be mentioned in the docu, and the difference between 4.x and 5.x behaviour, also because with 4.x magic_quotes_gpc is on by default. -- Edit this bug report at http://bugs.php.net/?id=40586edit=1
#35980 [Opn]: touch() works on files but not on directories (on Linux this works perfectly)
ID: 35980
Updated by: [EMAIL PROTECTED]
Reported By: pavel dot hlousek at gmail dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: *Directory/Filesystem functions
Operating System: Win2K
PHP Version: 4.4.1
New Comment:
I see no reason why this shouldn't work on Windows, it's definitely
possible.
Previous Comments:
[2006-01-12 18:38:46] [EMAIL PROTECTED]
So windows just doesn't support it - docu prob
[2006-01-12 16:17:05] pavel dot hlousek at gmail dot com
Description:
?php touch('non-existing-file'); ? - Correct. Creates a new file.
?php touch('existing-file'); ? - Correct. Changes file's mtime.
?php touch('existing-directory'); ? - Wrong on Win2K. Does not change
directory's mtime. Correct on Linux. I did not test any other Win32
platforms. Filesystem: NTFS. The user running the script owns
'existing-directory'. safe_mode=Off.
Reproduce code:
---
?php touch('existing-directory'); ?
Expected result:
Change mtime of an existing directory.
Actual result:
--
Utime failed: Permission denied in fullpath/to/existing-directory on
line 1
--
Edit this bug report at http://bugs.php.net/?id=35980edit=1
#35936 [Opn]: ini.zlib.output-compression Documentation
ID: 35936 Updated by: [EMAIL PROTECTED] Reported By: sBoisvert at bryxal dot ca Status: Open -Bug Type: Documentation problem +Bug Type: Output Control Operating System: XP -PHP Version: Irrelevant +PHP Version: 5.1.1 New Comment: php_enable_output_compression() is called only in PHP_RINIT_FUNCTION() and not in OnUpdate_zlib_output_compression(). Previous Comments: [2006-01-09 01:17:56] sBoisvert at bryxal dot ca Description: This has either not been fixed or crept back in. (Bug #17299) The documentation on http://ca3.php.net/manual/en/ref.zlib.php#ini.zlib.output-compression it states zlib.output_compression boolean/integer In runtime, it can be set only before sending any output. but any attempts to set ini_set(zlib.output_compression, on); ini_set(zlib.output_compression_level, 5); will NOT compress data before sending it. Either this is a bug that slipped in lately or a documentation problem. A comment has already been left by someone on this page commenting on his inability to make this work. Thank you Reproduce code: --- ini_set(zlib.output_compression, on); ini_set(zlib.output_compression_level, 5); echo(ini_get(zlib.output_compression)); Expected result: compressed: on Actual result: -- uncompressed: on -- Edit this bug report at http://bugs.php.net/?id=35936edit=1
#35925 [Bgs]: cpdf - invalid information (regarding PECL)
ID: 35925 Updated by: [EMAIL PROTECTED] Reported By: mfloryan at bigfoot dot com Status: Bogus Bug Type: Unknown/Other Function Operating System: linux PHP Version: 5.1.1 New Comment: Take a look at http://pecl4win.php.net/ext.php/php_cpdf.dll . It really has been moved to PECL but doesn't have its presentation at http://pecl.php.net yet. Previous Comments: [2006-01-08 18:07:49] mfloryan at bigfoot dot com Sorry, but I still insist it is a Documentation BUG because docs are incorrect regardles of the reason! [2006-01-07 23:00:26] [EMAIL PROTECTED] And nobody will create any entry but when the maintainers (if there is any) will release it. [2006-01-07 21:57:45] [EMAIL PROTECTED] And that's definately not a PHP problem! [2006-01-07 21:14:41] [EMAIL PROTECTED] The code is in fact in PECL'd cvs, but someone forgots to create an entry in PECL website. [2006-01-07 13:42:31] mfloryan at bigfoot dot com It only appears in versions 5.1.0+ 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/35925 -- Edit this bug report at http://bugs.php.net/?id=35925edit=1
#35270 [Fbk]: copying an array no longer resets the index
ID: 35270
Updated by: [EMAIL PROTECTED]
Reported By: andrej at blueshoes dot org
Status: Feedback
Bug Type: Arrays related
Operating System: windows
PHP Version: ?
New Comment:
This was originally a Documentation problem so Irrelevant was filled by
our bug system. I guess it's 4.4.1.
Previous Comments:
[2005-11-18 09:40:11] [EMAIL PROTECTED]
There is no such version as Irrelevant.
Or did you really try it with *ALL* versions since 1.0.0 ?
[2005-11-18 09:05:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-11-18 05:15:02] andrej at blueshoes dot org
Description:
the documentation for each
http://www.php.net/manual/en/function.each.php has a caution which was
true for php up to 4.3.11, but it's not for 4.4.1 anymore.
Reproduce code:
---
$array = array('a', 'b', 'c', 'd', 'e', 'f', 'g');
$breakAt = 3;
$i=0;
while (list($key, $val) = each($array)) {
if ($i $breakAt) break;
$i++;
}
$brray = $array;
$aCurrent = current($array);
$bCurrent = current($brray);
$actual = $aCurrent;
$expected = 'a';
$this-assertEquals($expected, $actual, failed? could be a good
thing. check the code.);
$actual = $bCurrent;
$expected = 'f';
$this-assertEquals($expected, $actual, failed? could be a good
thing.);
Expected result:
a or f
Actual result:
--
a or f
--
Edit this bug report at http://bugs.php.net/?id=35270edit=1
#35176 [Opn]: include()/require()/*_once() produce wrong error messages about main()
ID: 35176
Updated by: [EMAIL PROTECTED]
Reported By: subscription at nazarenko dot net
Status: Open
-Bug Type: Documentation problem
+Bug Type: PHP options/info functions
Operating System: SuSE Linux 10.0
PHP Version: 5CVS-2005-11-09 (CVS)
New Comment:
I removed the No longer points here column from function.main in
CVS.
This is maybe not easy to fix but it's still a bug:
1. Prior to function.require error message, there's a bogus
function.main error message - it should be silented.
2. require_once() points to function.require and not
function.require-once, include_once() parallel.
Previous Comments:
[2005-11-10 09:23:11] [EMAIL PROTECTED]
See also bug #21499.
[2005-11-09 22:32:11] [EMAIL PROTECTED]
The docs are wrong - I can see the same problem in 4.3.6 and 4.3.10.
Also, I don't see an easy way to fix it, since include_*()/require_*()
aren't really functions, but language constructs.
[2005-11-09 22:14:54] subscription at nazarenko dot net
Sorry, the script above should have
require_once('fake');
[2005-11-09 22:06:47] subscription at nazarenko dot net
A sample script:
?php
require_once('nonexisting');
?
Produces this HTML (html_errors=on):
bWarning/b: main(fake) [a
href='http://www.php.net/manual/en/function.main.php'function.main.php/a]:
failed to open stream: No such file or directory in bx.php/b on line
b2/bbr /
/span
bFatal error/b: main() [a
href='http://www.php.net/manual/en/function.require.php'function.require.php/a]:
Failed opening required 'fake' (include_path='.:/usr/lib/php') in
bx.php/b on line b2/bbr /
This illustrates both points: the erroneous main() function as well as
the wrong html link (should be funtion.require-once.php)
[2005-11-09 21:56:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
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/35176
--
Edit this bug report at http://bugs.php.net/?id=35176edit=1
#32701 [Bgs-Opn]: Safe-mode popen(): escaping problem
ID: 32701 Updated by: [EMAIL PROTECTED] Reported By: kosmo at miechow dot com -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: Linux PHP Version: 5.0.4 New Comment: It works bad. There's no way to echo '-= Test =-' in safe_mode. No characters inside single quotes should be escaped by php_escape_shell_cmd() as they have no special meaning. I can prepare a patch for it if it will be accepted. Previous Comments: [2005-04-14 09:51:57] [EMAIL PROTECTED] This is how it works. No bug here. [2005-04-14 09:22:15] kosmo at miechow dot com Description: In safe-mode popen() is escaping command line by calling php_escape_shell_cmd(). This funcion escaping command line, and changing valid command arguments. IMHO there should be any way to disable this escaping and run in safe-mode. Reproduce code: --- ?php $r = popen(echo '-= Test =-', r); print(stream_get_contents($r)); pclose($r); ? Expected result: -= Test =- Actual result: -- -=\ Test \=- -- Edit this bug report at http://bugs.php.net/?id=32701edit=1
#30257 [Opn]: Unexpected result of xml_get_current_byte_index and xml_get_current_column_numb
ID: 30257
Updated by: [EMAIL PROTECTED]
Reported By: christoffer at natlikan dot se
Status: Open
-Bug Type: Documentation problem
+Bug Type: XML related
Operating System: *
PHP Version: 5CVS-2005-02-02
New Comment:
It's so weird that it should be rather fixed than documented:
All functions point to the end of a tag instead of beginning. (it can
be documented)
xml_get_current_byte_index() and xml_get_current_column_number() behave
unpredictable (it should be fixed):
?xml version='1.0' encoding='us-ascii'?a/a CN=42, BI=4
?xml version='1.0' encoding='us-ascii' ?a/a CN=42, BI=5
?xml version='1.0' encoding='us-ascii'?a/a CN=42, BI=4
?xml version='1.0' encoding='utf-8'?a/a CN=39, BI=40
Another problem is with attribute values and whitespace. They are not
counted to CN (it should be fixed):
?xml version='1.0' encoding='utf-8'?a b=''/a CN=41, BI=45
?xml version='1.0' encoding='utf-8'? a b=''/a CN=41, BI=46
?xml version='1.0' encoding='utf-8'?a b=''/a CN=41, BI=46
?xml version='1.0' encoding='utf-8'?a b='cde'/a CN=41, BI=48
Such a weird behavior is nearly undocumentable and unusable for sure.
Previous Comments:
[2005-08-01 00:37:06] [EMAIL PROTECTED]
This difference is caused by the fact that in PHP5 we use libxml
instead of expat by default.
To get the expat behaviour, you can always compile PHP with
--with-expat-dir=/path/to/expat
This change in behaviour needs to be documented though.
[2004-09-30 01:27:16] olivier at samalyse dot com
I'm experiencing similar troubles with xml_get_current_byte_index().
But I don't agree with the expected result christoffer proposes.
Actually, in php4 xml_get_current_byte_index() behaves perfectly to me.
Using the test code below with php version 4.3.4 produces :
ElementOpen - Row: 2 Col: 0 BIndex: 44
ElementOpen - Row: 4 Col: 1 BIndex: 61
ElementOpen - Row: 5 Col: 2 BIndex: 67
ElementClose - Row: 5 Col: 8 BIndex: 73
ElementClose - Row: 6 Col: 1 BIndex: 79
ElementClose - Row: 7 Col: 0 BIndex: 84
Byte Index 44 points at the beginning of the a tag :
a b=x
^
That is fine.
Now, if you omit the xml declaration '?xml version=1.0
encoding=ISO-8859-1?', using php5, you will obtain :
ElementOpen - Row: 1 Col: 5 BIndex: 8
ElementOpen - Row: 3 Col: 8 BIndex: 19
ElementOpen - Row: 4 Col: 11 BIndex: 25
ElementClose - Row: 4 Col: 15 BIndex: 33
ElementClose - Row: 5 Col: 18 BIndex: 39
ElementClose - Row: 6 Col: 21 BIndex: 44
Byte index 8 does not point at the beginning of the tag anymore, but at
its end :
a b=x
^
In my particular case (XML indexing/marshalling) that's far less
usable. Some may consider that's no bug, but it breaks backward
compatibility with php4.
Now, if you let the xml declaration in place, this function does not
produce anything relevant anymore. As Christoffer reports, parsing this
xml document when it includes '?xml version=1.0
encoding=ISO-8859-1?' will produce :
ElementOpen - Row: 2 Col: 5 BIndex: 11
ElementOpen - Row: 4 Col: 8 BIndex: 22
ElementOpen - Row: 5 Col: 11 BIndex: 28
ElementClose - Row: 5 Col: 15 BIndex: 36
ElementClose - Row: 6 Col: 18 BIndex: 42
ElementClose - Row: 7 Col: 21 BIndex: 47
In this later case, what seems to happen is that the xml declaration
byte length is badly evaluated. If you add to this the fact that the
returned byte index points at the end of the tag (php5) instead of the
beginning of the tag (php4), it really starts to look like random
output...
[2004-09-27 20:36:13] christoffer at natlikan dot se
Description:
xml_get_current_byte_index and xml_get_current_column_number returns
unexpected values when the XML contains a XML declaration. Using
php5.0-win32-200409270830 and Apache/1.3.31.
Reproduce code:
---
?php
function elementOpen($parser, $elementName, $attributes) {
echo(ElementOpen - Row: .
xml_get_current_line_number($parser) .
Col: . xml_get_current_column_number($parser) .
BIndex: . xml_get_current_byte_index($parser) .
br /);
}
function elementClose($parser, $elementName) {
echo(ElementClose - Row: .
xml_get_current_line_number($parser) .
Col: . xml_get_current_column_number($parser) .
BIndex: . xml_get_current_byte_index($parser) .
br /);
}
$parser = xml_parser_create();
xml_parser_set_option($parser, XML_OPTION_CASE_FOLDING, false);
xml_set_element_handler($parser, elementOpen, elementClose);
$xml =
?xml version=\1.0\ encoding=\ISO-8859-1\?\n .
a b=\x\\n .
\ttest\n .
#33852 [Fbk-Bgs]: Strrpos: offset param works from the end
ID: 33852
Updated by: [EMAIL PROTECTED]
Reported By: sl at yes-co dot nl
-Status: Feedback
+Status: Bogus
Bug Type: Strings related
Operating System: Linux sarge 2.6.8
PHP Version: 5.1.0-dev
New Comment:
Quote whole parts and you will understand it: As of PHP 5.0.0 offset
may be specified to begin searching an arbitrary number of characters
into the string. Negative values will stop searching at an arbitrary
point prior to the end of the string.
Thus strrpos('0123456789', '3', 5) is equal to strrpos('.56789',
'3') and strrpos('0123456789', '3', -5) is equal to strrpos('012345',
'3').
Previous Comments:
[2005-07-25 12:34:27] [EMAIL PROTECTED]
There are two fields int the report form: one for the result you expect
to get and second for the result you actually get.
Please fill them both.
[2005-07-25 11:58:41] sl at yes-co dot nl
Offset also does not work from the end:
strrpos with offset
string: aaabbaaa
strrpos($string, 'b', 1): 16
strrpos($string, 'b', 5): 16
strrpos($string, 'b', 15): 16
strrpos($string, 'b', 19):
strrpos($string, 'b', -5): 3
strrpos($string, 'b', -15): 3
This does not make sense.
[2005-07-25 11:45:07] sl at yes-co dot nl
Description:
The offset parameter of the strrpos function is the offset from the end
of the string. The documentation is unclear about this:
As of PHP 5.0.0 offset may be specified to begin searching an
arbitrary number of characters into the string.
I would expect it to start at $string+$offset, searching backwards.
Reproduce code:
---
?php
echo strrpos with offset\n;
$string='abcdefghijklmnopqrstuvwxyz';
echo string: $string\n;
echo 'strrpos($string, \'n\', 5): '.strrpos($string, 'n', 5).\n;
echo 'strrpos($string, \'n\', 15): '.strrpos($string, 'n', 15).\n;
echo 'strrpos($string, \'n\', -5): '.strrpos($string, 'n', -5).\n;
echo 'strrpos($string, \'n\', -15): '.strrpos($string, 'n',
-15).\n;
?
Actual result:
--
strrpos with offset
string: abcdefghijklmnopqrstuvwxyz
strrpos($string, 'n', 5): 13
strrpos($string, 'n', 15):
strrpos($string, 'n', -5): 13
strrpos($string, 'n', -15):
--
Edit this bug report at http://bugs.php.net/?id=33852edit=1
#33240 [Fbk-Opn]: XML_OPTION_SKIP_WHITE skips important spaces
ID: 33240 Updated by: [EMAIL PROTECTED] Reported By: jacob at jacobweber dot com -Status: Feedback +Status: Open Bug Type: XML related Operating System: Fedora Core 3 PHP Version: 5.0.4 New Comment: I see. XML_OPTION_SKIP_WHITE skips values that constist of whitespace characters only. I documented that but the original problem remains (apos; amp; should become ' , not '). Previous Comments: [2005-06-06 23:41:00] [EMAIL PROTECTED] Perhaps you misunderstood how it works? Why do you think it should skip ALL whitespace? (given the fact it never was documented to do that or anything else :) [2005-06-06 17:06:50] [EMAIL PROTECTED] Options were added to the CVS docs but the problem remains. XML_OPTION_SKIP_WHITE skips almost nothing (e.g. a x x /a is processed as x x ). [2005-06-03 23:20:04] jacob at jacobweber dot com I noticed that, so maybe they're not meant to be used. But one of the two examples I posted is incorrect: it should skip the space all the time or never. [2005-06-03 23:13:42] [EMAIL PROTECTED] Yes, it skips whitespace when you set it to 1. Otherwise it will not skip it, it's left as is. I could not find the documentation for these options (on the page for xml_parser_set_option()): XML_OPTION_SKIP_WHITE XML_OPTION_SKIP_TAGSTART even as they seem to have existed since PHP 3? :) [2005-06-03 22:50:41] jacob at jacobweber dot com Description: Turning on XML_OPTION_SKIP_WHITE causes the space in the following XML to be skipped: aapos; amp;/a I believe this is incorrect. It doesn't skip the space in: aamp; apos;/a Jacob Reproduce code: --- $xmlStr = aapos; amp;/a; $xmlParser = xml_parser_create(); xml_parser_set_option($xmlParser, XML_OPTION_SKIP_WHITE, 1); xml_parse_into_struct($xmlParser, $xmlStr, $xmlArr); xml_parser_free($xmlParser); print_r($xmlArr); Expected result: Array ( [0] = Array ( [tag] = A [type] = complete [level] = 1 [value] = ' ) ) Actual result: -- Array ( [0] = Array ( [tag] = A [type] = complete [level] = 1 [value] = ' ) ) (note the missing space after the apostrophe -- Edit this bug report at http://bugs.php.net/?id=33240edit=1
#33240 [Opn]: XML_OPTION_SKIP_WHITE skips important spaces
ID: 33240 Updated by: [EMAIL PROTECTED] Reported By: jacob at jacobweber dot com Status: Open -Bug Type: Documentation problem +Bug Type: XML related Operating System: Fedora Core 3 -PHP Version: Irrelevant +PHP Version: 5.0.4 New Comment: Options were added to the CVS docs but the problem remains. XML_OPTION_SKIP_WHITE skips almost nothing (e.g. a x x /a is processed as x x ). Previous Comments: [2005-06-03 23:20:04] jacob at jacobweber dot com I noticed that, so maybe they're not meant to be used. But one of the two examples I posted is incorrect: it should skip the space all the time or never. [2005-06-03 23:13:42] [EMAIL PROTECTED] Yes, it skips whitespace when you set it to 1. Otherwise it will not skip it, it's left as is. I could not find the documentation for these options (on the page for xml_parser_set_option()): XML_OPTION_SKIP_WHITE XML_OPTION_SKIP_TAGSTART even as they seem to have existed since PHP 3? :) [2005-06-03 22:50:41] jacob at jacobweber dot com Description: Turning on XML_OPTION_SKIP_WHITE causes the space in the following XML to be skipped: aapos; amp;/a I believe this is incorrect. It doesn't skip the space in: aamp; apos;/a Jacob Reproduce code: --- $xmlStr = aapos; amp;/a; $xmlParser = xml_parser_create(); xml_parser_set_option($xmlParser, XML_OPTION_SKIP_WHITE, 1); xml_parse_into_struct($xmlParser, $xmlStr, $xmlArr); xml_parser_free($xmlParser); print_r($xmlArr); Expected result: Array ( [0] = Array ( [tag] = A [type] = complete [level] = 1 [value] = ' ) ) Actual result: -- Array ( [0] = Array ( [tag] = A [type] = complete [level] = 1 [value] = ' ) ) (note the missing space after the apostrophe -- Edit this bug report at http://bugs.php.net/?id=33240edit=1
#25456 [Opn]: It would be nice to have a php-config, phpextdist and phpize man pages.
ID: 25456 Updated by: [EMAIL PROTECTED] -Summary: It would be nice to have a phpextdist man page. Reported By: eseidel at apple dot com Status: Open -Bug Type: Documentation problem +Bug Type: CGI related Operating System: All PHP Version: 4.3.3 New Comment: Here are the files: http://www.vrana.cz/scite/phpscripts-man.tgz . I know only a little about the scripts and only a little about the man pages format. Can someone from the source code team revise the pages, add the files to the appropriate place (most probably sapi/cli where also php.1 lives) and arrange copying to the same folder as php.1 during the installation? I did my best. Previous Comments: [2005-01-08 00:57:58] eseidel at apple dot com Isn't that the problem to begin with? :) /usr/bin/phpextdist It's a simple script, it looks like it should just be removed from the install. [2004-12-30 00:01:56] [EMAIL PROTECTED] No clue what phpextdist is, so we can't make a man page for it. [2003-09-09 13:09:55] eseidel at apple dot com Description: phpextdist ships as an executable with php, but does not come with a corresponding man page. It would be nice to have a simple man page for phpextdist. Reproduce code: --- man phpextdist No manual entry for phpextdist Expected result: shows the man page Actual result: -- doesn't show a man page. -- Edit this bug report at http://bugs.php.net/?id=25456edit=1
#29514 [Opn]: auto_globals_jit not in php.ini
ID: 29514
Updated by: [EMAIL PROTECTED]
Reported By: holliwell at gmx dot net
Status: Open
-Bug Type: Documentation problem
+Bug Type: *Configuration Issues
Operating System: linux -2.4.20
PHP Version: 5.0.0
New Comment:
Docu people doesn't have karma to add it to php.ini, can someone from
source code guys do it?
Previous Comments:
[2005-04-11 09:28:04] [EMAIL PROTECTED]
A message was sent to php-internals with a patch for php.ini here:
* http://marc.theaimsgroup.com/?l=php-devm=111204914824598
[2005-02-25 22:31:07] [EMAIL PROTECTED]
This is now documented in the PHP Manual but still needs to find its
way into php.ini-{dist|recommended)
Here's the diff:
http://cvs.php.net/diff.php/phpdoc/en/appendices/ini.xml?r1=1.11r2=1.12ty=h
[2004-08-17 18:06:18] [EMAIL PROTECTED]
Changed to docu problem, 'cos it's not documented too. Probably Zeev
can tell about Just-In-Time variables initialization, as he was the
person who implemented it.
[2004-08-03 23:59:30] holliwell at gmx dot net
Description:
Hi,
phpinfo() reports about auto_globals_jit, but this directive is neither
in php.ini-dist nor php.ini-recommended.
Regards
Friedhelm Betz
--
Edit this bug report at http://bugs.php.net/?id=29514edit=1
#27633 [Csd]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa New Comment: Works for me, thanks! Previous Comments: [2005-03-11 00:38:31] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-23 09:59:31] [EMAIL PROTECTED] Ilia, your fix did not work? :) [2005-02-23 09:37:21] [EMAIL PROTECTED] It's the same with the latest Windows snapshot :-(. [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. 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/27633 -- Edit this bug report at http://bugs.php.net/?id=27633edit=1
#29737 [Csd-Opn]: ip2long() works not as documented
ID: 29737 Updated by: [EMAIL PROTECTED] Reported By: belikoviv at is dot lg dot ua -Status: Closed +Status: Open -Bug Type: Documentation problem +Bug Type: Network related Operating System: Windows 2000 SP4; Fedora Core 2 PHP Version: 5.0.0 New Comment: The function is returning -1 also for any substring of 255.255.255.255 (e.g. or 255.) but it should return FALSE. memcmp(Z_STRVAL_PP(str), 255.255.255.255, Z_STRLEN_PP(str)) should be replaced by strcmp(Z_STRVAL_PP(str), 255.255.255.255). Previous Comments: [2005-04-06 15:23:10] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. ip2long() will return FALSE for the IP 255.255.255.255 in PHP 5 = 5.0.2. It was fixed in PHP 5.0.3 where it returns -1 (same as PHP 4). [2005-04-06 12:16:43] belikoviv at is dot lg dot ua Function ip2long() fixed long time ago, but now I see incorrect note in documentation (at bottom of the chapter): Note: ip2long() will return -1 (PHP 4) or FALSE (PHP 5) for the IP 255.255.255.255 This is incorrect. ip2long returns -1 in both PHP4 and PHP5 for IP 255.255.255.255. Value -1 is _correct_ value for 255.255.255.255, so that note must be deleted from documentation. Note about PHP4 is exist near the top of chapter. [2004-08-19 18:44:43] [EMAIL PROTECTED] Be patient, Win32 snaps are not ready yet. Latest PHP5 win32 snapshot was built on: Aug 19, 2004 08:30 GMT. [2004-08-19 18:18:25] belikoviv at is dot lg dot ua Sorry, but problem not fixed - I try php5-win32-latest.zip and php5.0-win32-200408190830.zip. Both snapshots return FALSE on address 255.255.255.255. [2004-08-19 16:04:35] [EMAIL PROTECTED] Fixed in CVS, 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/29737 -- Edit this bug report at http://bugs.php.net/?id=29737edit=1
#28264 [Opn-Csd]: SQLite not doing multiple queries
ID: 28264
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Closed
-Bug Type: Documentation problem
+Bug Type: SQLite related
Operating System: Win 2K Pro
PHP Version: 5CVS-2004-05-03 (dev)
New Comment:
It's already documented:
sqlite_query:
SQLite will execute multiple queries ... However, this works only when
the result of the function is not used - if it is used, only the first
SQL statement would be executed.
Changing back the state to Closed SQLite.
Previous Comments:
[2005-04-05 01:49:36] csaba at alum dot mit dot edu
It's unclear to me from the earlier comments that fixed means there is
another function which mostly does what this one is documented as
supposed to be doing (and today's earlier rejoinder is the the first
mention of sqlite_exec). Nevertheless, I had tested with sqlite_exec
before submitting the report earlier today, and yes, it does do
multiple queries.
To me, fixed includes the documentation agreeing with observed
behaviour. As I noted in the original report, the documentation for
sqlite_query says that SQLite will execute multiple queries. If the
code isn't going to change, perhaps the documentation should.
Therefore, I have reclassified the Category as 'Documentation problem'.
[2005-04-05 01:19:18] [EMAIL PROTECTED]
It was fixed: You need to use sqlite_exec() instead of sqlite_query()
(took about 2 minutes for me to figure out and I don't use SQLite at
all..)
[2005-04-04 22:00:25] csaba at alum dot mit dot edu
This is still behaving in the same way as originally described (just
tested on PHP 5.0.4-dev 11-Mar-2005). Here is slightly nicer code to
show the problem:
?php
$db = sqlite_open(':memory:', 0666, $sqliteerror);
$tbl = delme;
$multiQuery = CREATE TABLE $tbl .
(foo INTEGER PRIMARY KEY, bar TEXT); .
INSERT INTO $tbl VALUES (null, 'Hi Mom');;
$dbRes = sqlite_query ($db, $multiQuery);
$creationTest = PRAGMA table_info('$tbl');;
$insertTest = SELECT * FROM $tbl;;
$acT = sqlite_array_query ($db, $creationTest, SQLITE_ASSOC);
print brbrTable was created:br;
var_dump ($acT);
$aiT = sqlite_array_query ($db, $insertTest, SQLITE_ASSOC);
print brbr;
if ($aiT)
{print with rows:br; var_dump ($aiT); }
else print but nothing was inserted;
?
Csaba
[2004-07-10 15:14:35] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in CVS.
http://cvs.php.net/diff.php/pecl/sqlite/sqlite.c?r1=1.62.2.21r2=1.62.2.22ty=u
[2004-05-27 00:15:40] saleh at sfsj dot net
I also want to add that even if you try to use transactions to execute
multiple queries..
I tried to use BEGIN; and BEGIN TRANSACTION; but both of them will not
work and nothing will happen..
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/28264
--
Edit this bug report at http://bugs.php.net/?id=28264edit=1
#31736 [Opn-Csd]: E_PARSE on include() and include_once() stops execution
ID: 31736 Updated by: [EMAIL PROTECTED] Reported By: jakent at gmail dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Any PHP Version: 5.0.3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. include: Be warned that parse error in required file doesn't cause processing halting in PHP versions prior to PHP 4.3.5. Since this version, it does. Previous Comments: [2005-01-28 08:26:17] jakent at gmail dot com Description: It appears that bug #26814 caused a minor change in how include, include_once, require, and require_once function. In spirit of how include works versus require, I would like to see execution continue on include and include_once E_PARSE errors. It makes sense for require and require_once to stop script execution, since failure causes a fatal error, while include and include_once only issue a warning. If nothing happens with this, the documentation needs to be changed. Be warned that parse error in required file doesn't cause processing halting. is still present. It would help a lot if include reflects the documented behavior once again. Jeff Kent Reproduce code: --- (file 1) test.php ?php @include no_exist.php; echo Test1\n; @include e_parse.php; echo Test2\n; ? (file 2) e_parse.php ?php echo Parse error\n ? Expected result: Test1 Test2 Actual result: -- Test1 -- Edit this bug report at http://bugs.php.net/?id=31736edit=1
#32594 [Opn-Csd]: missing dll in download
ID: 32594 Updated by: [EMAIL PROTECTED] Reported By: mazdaf at yahoo dot com -Status: Open +Status: Closed Bug Type: Other web server Operating System: win 2003 PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-04-05 19:13:59] [EMAIL PROTECTED] Not a docproblem. [2005-04-05 19:11:46] mazdaf at yahoo dot com Description: In the install file, it says The directory structure extracted from the zip is different for PHP versions 4 and 5 and look like as follows: Example 2-1. PHP 4 package structure +--sapi-- SAPI (server module support) DLLs | | | |-php4activescript.dll | | | |-php4apache.dll | | | |-php4apache2.dll | | | |-.. --- but there is no php4activescript.dll file in the 4.3.11 download in the Windows Binaries/PHP 4.3.11 zip package [7,289Kb] - 31 Mar 2005 download. -- Edit this bug report at http://bugs.php.net/?id=32594edit=1
#32337 [Opn]: Per Directory Values registry not working
ID: 32337 Updated by: [EMAIL PROTECTED] Reported By: jsonger at maintree dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows 2000 PHP Version: 5.0.3 New Comment: Documented for now in XML sources. Previous Comments: [2005-03-19 21:54:07] baricak at post dot cz [EMAIL PROTECTED], i am sorry, what is your point? I was setting up different servers last week, with Apache and .htaccess there was not any problem. Just because these scripts have to be at the IIS, I do not come around it. I thought the sense of Per Directory Values Windows Registry paradigm was reading out the registry at the starting point of IIS, and setting local values for some directories, for specific configuration settings. According to http://de3.php.net/manual/en/ini.php#ini.list register_globals is of type PHP_INI_PERDIR, which actually means you can set it locally. Moreover, with Apache1.3 and Apache2.0 this actually WORKS! So what's wrong with the Windows implementation? I would not turn my scripts to register_globals on, but just as jsonger I have some external scripts running on this server. Thats why I want to have php.ini set to register_globals off and turn it on just for the foreign scripts... [2005-03-18 20:10:13] jsonger at maintree dot com It read point needs to be adjusted then so it can work for register_globals. I don't want to for register_globals on for everyone just because a couple of my customers have older scripts that like it. I also don't understand why this is such a problem since the Apache module can do it with a .htaccess file. In a practicle since, I don't see a difference between the .htaccess file in apache and the registry in IIS. [2005-03-18 19:16:00] [EMAIL PROTECTED] This registry thing does NOT work for any option. It's just before script execution so it techinally can't work with e.g. register_globals. [2005-03-17 10:38:53] baricak at post dot cz And Last But not Least: When I try to echo ini_get(ini_directive); ,the value is correct as set in the registry, but the system does not work like it says- phpinfo() returns the old php.ini value and the system reacts as only the old php.ini was set. [2005-03-17 10:30:23] baricak at post dot cz Hello, I have the same problems. I just installed php5.0-win32-200503170130.zip on IIS5 with Windows 2000 as ISAPI module and Per Directory Values does not work with some of the settings. For instance, display_errors directive works fine, but register_globals DOES NOT. The another problem is, phpinfo() output is not correct. When I set display_errors in the registry to a different value as in php.ini, in the output of phpinfo() the value of local column stays untouched, even though the system reactions are like the new value was set. The Version 5.0.3 has the same problems. 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/32337 -- Edit this bug report at http://bugs.php.net/?id=32337edit=1
#27633 [Fbk]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa New Comment: It's the same with the latest Windows snapshot :-(. Previous Comments: [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch [2004-03-18 07:27:30] [EMAIL PROTECTED] Description: ftp_get() translates \n characters wrong in FTP_ASCII mode. Instead of \r\n, they become \r on Windows. Only newline at the end of a file (if any) is translated correct. \r\n on remote server become \r\r. Reproduce code: --- ?php $ftp = ftp_connect(ftp.netscape.com); ftp_login($ftp, anonymous, anonymous); ftp_pasv($ftp, true); ftp_get($ftp, Welcome, Welcome, FTP_ASCII); ftp_close($ftp); ? Expected result: \r\nWelcome ...\r\n Actual result: -- \rWelcome ...\r\n -- Edit this bug report at http://bugs.php.net/?id=27633edit=1
#27633 [Fbk-Opn]: Double \r problem on ftp_get in ASCII mode on Win32
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: FTP related Operating System: win32 only PHP Version: 4CVS, 5CVS (2005-02-22) Assigned To: iliaa Previous Comments: [2005-02-23 09:37:21] [EMAIL PROTECTED] It's the same with the latest Windows snapshot :-(. [2005-02-23 04:54:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There was some problem with win32 snapshots again.. [2005-02-21 12:20:51] [EMAIL PROTECTED] I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch 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/27633 -- Edit this bug report at http://bugs.php.net/?id=27633edit=1
#27633 [Csd-Opn]: vrana
ID: 27633 Updated by: [EMAIL PROTECTED] -Summary: [PATCH] Wrong translation in ASCII mode Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: FTP related Operating System: Windows XP PHP Version: 4.3.8 Assigned To: iliaa New Comment: I can't see any change: \n becomes \r\r on 5.1.0-dev (200502210730) \n becomes \r\r on 5.0.4-dev (200502210930) \n becomes \r\r\n on 4.3.11-dev (200502210530) last \n becomes \r\r\n on 5. Previous Comments: [2005-02-17 16:38:41] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-02-03 03:20:09] [EMAIL PROTECTED] http://www.binam.net/bug-27633.patch [2004-12-11 00:11:58] sirbinam at hotmail dot com I submitted a patch to the internals list. It worked for me. :) [2004-07-23 17:55:56] [EMAIL PROTECTED] \n becomes \r\r\n in PHP 4.3.8. \n becomes \r\r in PHP 5.0.0 (last \n becomes \r\r\n). [2004-07-23 16:38:01] a dot hoekstra at boxitbv dot nl Upgraded from 4.3.1 to 4.3.8. After upgrade I got extra cr at end of line when ftp in ascii mode from unix host to xp client. In case of large file (+3kb) missing tail of file and no error message! Downgraded again to 4.3.1 to make things work :-(. 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/27633 -- Edit this bug report at http://bugs.php.net/?id=27633edit=1
#31821 [Opn-Csd]: XML parse error not reported
ID: 31821 Updated by: [EMAIL PROTECTED] Reported By: jsmestad at advantageline dot com -Status: Open +Status: Closed -Bug Type: Documentation problem +Bug Type: *XML functions Operating System: Windows XP Professional SP2 PHP Version: 5CVS-2005-02-02 (dev) New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2005-02-07 21:43:16] jsmestad at advantageline dot com As stated, I believe this to be a documentation problem. [2005-02-04 15:18:33] jsmestad at advantageline dot com The documentation does not make the behavior of the parser obvious. It states this: When the XML document is parsed, the handlers for the configured events are called as many times as necessary, after which this function returns TRUE or FALSE. TRUE is returned if the parse was successful, FALSE if it was not successful, or if parser does not refer to a valid parser. For unsuccessful parses, error information can be retrieved with xml_get_error_code(), xml_error_string(), xml_get_current_line_number(), xml_get_current_column_number() and xml_get_current_byte_index(). For that string of XML, the parse was unsuccessful, and yet that particular call to xml_parse returns true. This behavior is contrary to the documentation. It states, and I repeat, TRUE is returned if the parse was successful, FALSE if it was not successful, or if parser does not refer to a valid parser. Yet, true is returned also if the parse is unsuccessful and not specified as complete by the is_final flag. [2005-02-04 14:21:33] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php you need to set is_final flag for the error to appear when using libxml rather than expat so that libxml knows that all the data has been passed to the parser: xml_parse($xml_parser,thdocthisthisthat/thisthatthatdata/that/thdoc, TRUE); [2005-02-02 22:20:59] jsmestad at advantageline dot com Description: The XML parser does not return an error when expected. Reproduce code: --- $xml_parser = xml_parser_create(); xml_set_element_handler($xml_parser, startTag, endTag); xml_set_character_data_handler($xml_parser, cdata); $data = xml_parse($xml_parser,thdocthisthisthat/thisthatthatdata/that/thdoc); printf(%s at line %d, xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser)); Expected result: not well-formed (invalid token) at line 1 Actual result: -- No error at line 1 -- Edit this bug report at http://bugs.php.net/?id=31821edit=1
#31821 [Csd]: XML parse error not reported
ID: 31821 Updated by: [EMAIL PROTECTED] Reported By: jsmestad at advantageline dot com Status: Closed Bug Type: *XML functions Operating System: Windows XP Professional SP2 PHP Version: 5CVS-2005-02-02 (dev) New Comment: Fixed by: Entity errors are reported at the end of the data thus only if is_final is set and TRUE. Previous Comments: [2005-02-13 22:30:00] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2005-02-07 21:43:16] jsmestad at advantageline dot com As stated, I believe this to be a documentation problem. [2005-02-04 15:18:33] jsmestad at advantageline dot com The documentation does not make the behavior of the parser obvious. It states this: When the XML document is parsed, the handlers for the configured events are called as many times as necessary, after which this function returns TRUE or FALSE. TRUE is returned if the parse was successful, FALSE if it was not successful, or if parser does not refer to a valid parser. For unsuccessful parses, error information can be retrieved with xml_get_error_code(), xml_error_string(), xml_get_current_line_number(), xml_get_current_column_number() and xml_get_current_byte_index(). For that string of XML, the parse was unsuccessful, and yet that particular call to xml_parse returns true. This behavior is contrary to the documentation. It states, and I repeat, TRUE is returned if the parse was successful, FALSE if it was not successful, or if parser does not refer to a valid parser. Yet, true is returned also if the parse is unsuccessful and not specified as complete by the is_final flag. [2005-02-04 14:21:33] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php you need to set is_final flag for the error to appear when using libxml rather than expat so that libxml knows that all the data has been passed to the parser: xml_parse($xml_parser,thdocthisthisthat/thisthatthatdata/that/thdoc, TRUE); [2005-02-02 22:20:59] jsmestad at advantageline dot com Description: The XML parser does not return an error when expected. Reproduce code: --- $xml_parser = xml_parser_create(); xml_set_element_handler($xml_parser, startTag, endTag); xml_set_character_data_handler($xml_parser, cdata); $data = xml_parse($xml_parser,thdocthisthisthat/thisthatthatdata/that/thdoc); printf(%s at line %d, xml_error_string(xml_get_error_code($xml_parser)), xml_get_current_line_number($xml_parser)); Expected result: not well-formed (invalid token) at line 1 Actual result: -- No error at line 1 -- Edit this bug report at http://bugs.php.net/?id=31821edit=1
#28459 [Opn-Ver]: Documentation and Object/class problem
ID: 28459
Updated by: [EMAIL PROTECTED]
Reported By: alpzrjvr at hotmail dot com
-Status: Open
+Status: Verified
Bug Type: Class/Object related
-Operating System: Slackware 9.0
+Operating System: Slackware 9.0, Windows XP
-PHP Version: 4.3.6
+PHP Version: 4.3.8
Previous Comments:
[2004-05-20 20:04:59] alpzrjvr at hotmail dot com
Description:
http://cr2.php.net/language.oop.constructor
PHP manual says:
In PHP 3, the function B() in class A will suddenly become a
constructor in class B, although it was never intended to be. The rule
in PHP 3 is: 'A constructor is a function of the same name as the
class.'. PHP 3 does not care if the function is being defined in class
B, or if it has been inherited.
This is fixed in PHP 4 by modifying the rule to: 'A constructor is a
function of the same name as the class it is being defined in.'. Thus
in PHP 4, the class B would have no constructor function of its own and
the constructor of the base class would have been called, printing 'I am
the constructor of A.br /'.
But, I test the script in diferent PHP's versions and the result was:
I am a regular function named B in class A.
I am not a constructor in A. ... with PHP 4.x.x .
Reproduce code:
---
?
class A
{
function A()
{
echo I am the constructor of A.br /\n;
}
function B()
{
echo I am a regular function named B in class A.br /\n;
echo I am not a constructor in A.br /\n;
}
}
class B extends A
{
function C()
{
echo I am a regular function.br /\n;
}
}
$b = new B();
or
$b = new B; (also works)
?
Expected result:
I am the constructor of A.
Actual result:
--
I am a regular function named B in class A.
I am not a constructor in A.
--
Edit this bug report at http://bugs.php.net/?id=28459edit=1
#29712 [Opn-Csd]: ereg() does not return TRUE
ID: 29712
Updated by: [EMAIL PROTECTED]
Reported By: liit at geeksbynature dot dk
-Status: Open
+Status: Closed
Bug Type: Regexps related
Operating System: Gentoo Linux
PHP Version: 4.3.8
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
If the optional parameter regs was not passed or the length of the
matched string is 0, this functions returns 1.
Previous Comments:
[2004-09-06 21:27:20] [EMAIL PROTECTED]
If I understand, this function should return the legth of the match.
But it seems it has a bug, because it always return 1 if you don't pass
the 3rd parameter. Or is it a feature that should be documented?
?
echo ereg('foo', 'foo foo foo'); //1
echo ereg('foo', 'foo foo foo', $var); //3
echo ereg('foobar', 'foobar foo foo', $var2); //6
?
Nuno
[2004-08-29 18:10:00] liit at geeksbynature dot dk
ereg() still only returns int(1) or (boolean)FALSE. I've expanded my
test-script a bit:
?php
$a = ereg(fo,fo); // Simple test to see if documentation is right
(it's not)
$b = ereg(bar,foobarbar); // Is it the position of the first
result, that is returned ? (no)
$c = ereg(foo,bar); // A negative test (works)
echo $a . : . gettype($a). \n;
echo $b . : . gettype($b). \n;
echo $c . : . gettype($c). \n;
?
Result:
1:integer
1:integer
:boolean
According to the docs, it should be:
2:integer
3:integer
:boolean
[2004-08-17 00:40:12] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources.
The changes may not appear immediately, since the online and
downloadable versions of the documentation need some time to get
updated. We would therefore like to ask for your patience in this
matter.
Thank you for the report, and for helping us make our documentation
better.
[2004-08-17 00:12:47] [EMAIL PROTECTED]
ereg() returns the length of the matched string on success,
the documentation is wrong.
[2004-08-16 20:57:24] liit at geeksbynature dot dk
Description:
The function ereg() either returns (boolean)FALSE or (int)1, and not
(boolean)FALSE or (boolean)TRUE
Reproduce code:
---
echo gettype(ereg(foo,foo));
echo gettype(ereg(foo,bar));
Expected result:
boolean
boolean
Actual result:
--
integer
boolean
--
Edit this bug report at http://bugs.php.net/?id=29712edit=1
#24071 [Csd-Opn]: 4.3.2 fopen(filename, a) not place file pointer to the end.
ID: 24071
Updated by: [EMAIL PROTECTED]
Reported By: artem at w510 dot tm dot odessa dot ua
-Status: Closed
+Status: Open
-Bug Type: Documentation problem
+Bug Type: Filesystem function related
Operating System: redhat
PHP Version: 4.3.2
New Comment:
From code at php-src/main/streams/streams.c:1693 (revision 1.61) it
seems that this is supposed to work (but doesn't).
if (stream stream-ops-seek (stream-flags
PHP_STREAM_FLAG_NO_SEEK) == 0 strchr(mode, 'a') stream-position
== 0) {
off_t newpos = 0;
/* if opened for append, we need to revise our idea of the initial
file position */
if (0 == stream-ops-seek(stream, 0, SEEK_CUR, newpos TSRMLS_CC))
{
stream-position = newpos;
}
}
If it will be fixed, reclasify this back to docprob so we can add a
note that it works since version x.x.x.
(Spotted by [EMAIL PROTECTED])
Previous Comments:
[2004-08-07 10:56:50] [EMAIL PROTECTED]
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
ftell() gives undefined results for append-only streams (opened with
a flag).
[2003-06-06 18:33:38] artem at w510 dot tm dot odessa dot ua
maybe,
but i used this without any problem from version 4.0 (one of first) to
store initial append position - that' about some years...
and it's worked through updates up to 4.2.3
[2003-06-06 18:11:03] [EMAIL PROTECTED]
'a' mode forces the kernel to always write at the end of the file.
ftell() will give undefined results for append-only streams, as will
seeking.
Writing to such a file should always be appended, regardless of the
results from ftell().
Making this a documentation problem.
[2003-06-06 17:46:09] artem at w510 dot tm dot odessa dot ua
after installing 4.3.2
$fr = fopen(filename, a);
$pointer = ftell($fr);
points to 0! forced to add
fseek($fr, 0, SEEK_END);
$pointer = ftell($fr);
to move to the file end
--
Edit this bug report at http://bugs.php.net/?id=24071edit=1
#16387 [Opn]: PHP loop when using reference to an object in an object (both in session)
ID: 16387
Updated by: [EMAIL PROTECTED]
Reported By: caugustin at alcyonis dot fr
Status: Open
-Bug Type: Documentation problem
+Bug Type: Session related
Operating System: ANY
PHP Version: Irrelevant
New Comment:
Warning added to manual: You can't use references in session variables
as there is no feasible way to restore reference to other variable.
Leaving open and reclasified at request of yohgaki.
Previous Comments:
[2004-06-06 15:59:47] dvck0 at galaxienet dot cz
i have same problem with store object with references
i register $Session
$Session-Modules-Module-Modules = $Session-Modules;
firsttime not loop, but if session restore object, make 6-12 loop, php
not tell me, i find this if store data to DB and 1 record is stored
6-12times, this is bad for PHP, i like programing with class, i must
rewrite all code :((
[2002-04-02 08:41:44] [EMAIL PROTECTED]
I'll make this a documentation problem for now.
Even if we made PHP not to crash with reference, there is no feasible
way to restore reference to other variable.
If anyone documented the issue, please change category back to Session
Related and keep this report open. PHP should warn if user uses
reference in session vars.
[2002-04-02 05:47:41] [EMAIL PROTECTED]
It's known issue.
Reference does not work well with session variable...
[2002-04-02 05:29:01] caugustin at alcyonis dot fr
Hello, I don't know if it is really a bug, but it display nothing in
error log and it is very anoying.
I create an object 'order' and an object 'customer'. The order object
has a customer object inside. To avoid duplicate in session I tried the
following code when the customer login and have already started to
order:
$current_order-customer = $current_customer;
After this, PHP display the current page well, but any next page fail
to display. Nothing apear in error_log. On a personal log system I can
see that PHP is starting to loop on the page juste after the session is
initialized and when the line
session_register('current_customer');
is called. PHP hang after about 20 loops.
After reading in detail the way session are working, I understand
better that my code is a little bit dangerous (use reference in
session), but PHP should return an error or display anything when it
face this king of code and not enter in an invisible loop.
Cedric.
--
Edit this bug report at http://bugs.php.net/?id=16387edit=1
#27633 [Csd-Opn]: Wrong translation in ASCII mode
ID: 27633 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: FTP related Operating System: Windows XP -PHP Version: 4.3.5RC3 +PHP Version: 4.3.8 New Comment: \n becomes \r\r\n in PHP 4.3.8. \n becomes \r\r in PHP 5.0.0 (last \n becomes \r\r\n). Previous Comments: [2004-07-23 16:38:01] a dot hoekstra at boxitbv dot nl Upgraded from 4.3.1 to 4.3.8. After upgrade I got extra cr at end of line when ftp in ascii mode from unix host to xp client. In case of large file (+3kb) missing tail of file and no error message! Downgraded again to 4.3.1 to make things work :-(. [2004-03-18 12:07:48] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2004-03-18 07:27:30] [EMAIL PROTECTED] Description: ftp_get() translates \n characters wrong in FTP_ASCII mode. Instead of \r\n, they become \r on Windows. Only newline at the end of a file (if any) is translated correct. \r\n on remote server become \r\r. Reproduce code: --- ?php $ftp = ftp_connect(ftp.netscape.com); ftp_login($ftp, anonymous, anonymous); ftp_pasv($ftp, true); ftp_get($ftp, Welcome, Welcome, FTP_ASCII); ftp_close($ftp); ? Expected result: \r\nWelcome ...\r\n Actual result: -- \rWelcome ...\r\n -- Edit this bug report at http://bugs.php.net/?id=27633edit=1
#28639 [Opn-Ver]: imageCreateFromGif infinite loop. max processor
ID: 28639 Updated by: [EMAIL PROTECTED] Reported By: jim at bluedojo dot com -Status: Open +Status: Verified Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.7 New Comment: It seems this is Windows specific issue caused most probably by php_gd2.dll. Previous Comments: [2004-06-06 20:04:26] jim at bluedojo dot com Yes, the images are corrupt. I believe that is why the function imageCreateFromGif() is going into an infinite loop. I need to have the function just exit and not loop infinitely. When I run the php page from the command line it goes into an infinite loop. When I load the php page from an Apache web server, it causes Apache to stall infinitely. My processor maxes out and I have to go to the Windows Task Menu to cancel the process. I am running the following: Windows XP Apache/1.3.28 PHP/4.3.7 GD library is turned on in php.ini Any help would be greatful. Thanks. [2004-06-06 18:32:07] [EMAIL PROTECTED] The 2 gif images you've offered are corrupt, and I cannot replicate the cpu usage you are reporting. [2004-06-05 20:00:26] jim at bluedojo dot com This picture also causes processor to max out: http://www.geocities.com/Tokyo/Palace/5677/riiya1.gif [2004-06-05 05:55:24] jim at bluedojo dot com Description: For some reason, this gif causes the processor to max out at 100% when imageCreateFromGif() function is used. Reproduce code: --- ? imageCreateFromGif(http://members.tripod.com/~TyroneZero/drstrangelove.gif;); ? Expected result: Creates a GD image Actual result: -- Infinite Loop. Maxes out processor. Causes operating system to stall. -- Edit this bug report at http://bugs.php.net/?id=28639edit=1
#22083 [Csd]: php-cli MySQL charset problem
ID: 22083 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz Status: Closed Bug Type: MySQL related Operating System: Windows PHP Version: 4.3.0 New Comment: my.ini is still ignored - it will not be fixed. You must have charsets directory in c:\mysql\share\charsets. Previous Comments: [2004-01-04 17:02:35] selfman at netax dot sk My APACHE error log is full of this: File 'c:\mysql\share\charsets\?.conf' not found (Errcode: 2) Character set '#26' is not a compiled character set and is not specified in the 'c:\mysql\share\charsets\Index' file The mysql is not located in the default directory. I am using the my.cnf to configure the mysql deamon. [mysqld] port=3306 skip-locking set-variable = key_buffer=16M set-variable = lower_case_table_names=0 set-variable = max_allowed_packet=1M set-variable = thread_stack=128K set-variable = flush_time=1800 default-character-set=win1250 skip-innodb basedir = C:/WWW/MySQL/ [2004-01-02 12:39:21] spam at vrana dot cz It's OK in 4.3.4. my.ini is still ignored, but there are no double backslash. [2004-01-02 12:31:37] selfman at netax dot sk The bug reappears in PHP 4.3.4 Win32 ISAPI Module for apache. [2003-03-27 07:29:35] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-02-05 15:52:19] spam at vrana dot cz When I set default-character-set=win1250 in my.ini, php-cli says: File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2) Character set '#26' is not a compiled character set and is not specified in the 'c:\mysql\\share\charsets\Index' file The problem is, that php-cli ignores character-sets-dir= in my.ini and uses its own hard-coded path c:\mysql\. If I move the share\charsets\ directory into c:\mysql\, the problem is still here because there are two backslashes in path, where php-cli tries to find it. When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and move share\charsets\ directory there, everything is working. Solution: 1. Change the default path for finding charsets from c:/mysql/ to c:/mysql 2. If possible, read character-sets-dir= from C:\Windows\my.ini. -- Edit this bug report at http://bugs.php.net/?id=22083edit=1
#26381 [Csd]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz Status: Closed Bug Type: Scripting Engine problem Operating System: win32 only PHP Version: 4CVS-2003-12-7 New Comment: I'm curious where the problem was. Can you please tell me? Previous Comments: [2004-01-19 14:04:45] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2003-12-07 13:54:15] [EMAIL PROTECTED] Indeed, this does happen with the php.ini-dist.. but doesn't if you do 'php -n' (no ini file) [2003-12-03 03:31:52] spam at vrana dot cz It behaves like that with php.ini-dist. It doesn't with php.ini-recommended. If I remove part Dynamic Extensions in php.ini-dist, it disappears. I mean part from ;; ; Dynamic Extensions ; ;; to ;;; ; Module Settings ; ;;; You know that everything is commented in this part in php.ini-dist. [2003-12-02 17:11:37] [EMAIL PROTECTED] We need the php.ini file causing the problems. [2003-12-02 10:57:15] spam at vrana dot cz I can't believe myself, the problem is caused by something completely different. I discovered that the problem occurs only under this circumstances: 1. Lines in php.ini file ends by CRLF. 2. Windows Extensions part in php.ini is longer than 503 characters (including new-lines). I don't know what is it but it looks like buffer overflow or something like that. So the problem is probably in php-src/main/php_ini.c or somewhere near. 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#22083 [Csd]: php-cli MySQL charset problem
ID: 22083 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz Status: Closed Bug Type: MySQL related Operating System: Windows PHP Version: 4.3.0 New Comment: It's OK in 4.3.4. my.ini is still ignored, but there are no double backslash. Previous Comments: [2004-01-02 12:31:37] selfman at netax dot sk The bug reappears in PHP 4.3.4 Win32 ISAPI Module for apache. [2003-03-27 07:29:35] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2003-02-05 15:52:19] spam at vrana dot cz When I set default-character-set=win1250 in my.ini, php-cli says: File 'c:\mysql\\share\charsets\?.conf' not found (Errcode: 2) Character set '#26' is not a compiled character set and is not specified in the 'c:\mysql\\share\charsets\Index' file The problem is, that php-cli ignores character-sets-dir= in my.ini and uses its own hard-coded path c:\mysql\. If I move the share\charsets\ directory into c:\mysql\, the problem is still here because there are two backslashes in path, where php-cli tries to find it. When I hexa edited php4ts.dll and change c:/mysql/ to c:/mysql3 and move share\charsets\ directory there, everything is working. Solution: 1. Change the default path for finding charsets from c:/mysql/ to c:/mysql 2. If possible, read character-sets-dir= from C:\Windows\my.ini. -- Edit this bug report at http://bugs.php.net/?id=22083edit=1
#26381 [Fbk-Opn]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4CVS-2003-12-2 New Comment: It behaves like that with php.ini-dist. It doesn't with php.ini-recommended. If I remove part Dynamic Extensions in php.ini-dist, it disappears. I mean part from ;; ; Dynamic Extensions ; ;; to ;;; ; Module Settings ; ;;; You know that everything is commented in this part in php.ini-dist. Previous Comments: [2003-12-02 17:11:37] [EMAIL PROTECTED] We need the php.ini file causing the problems. [2003-12-02 10:57:15] spam at vrana dot cz I can't believe myself, the problem is caused by something completely different. I discovered that the problem occurs only under this circumstances: 1. Lines in php.ini file ends by CRLF. 2. Windows Extensions part in php.ini is longer than 503 characters (including new-lines). I don't know what is it but it looks like buffer overflow or something like that. So the problem is probably in php-src/main/php_ini.c or somewhere near. [2003-11-24 08:21:33] spam at vrana dot cz Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Opn]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz -Summary: rand() without srand() doesn't work Reported By: spam at vrana dot cz Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4.3.3 New Comment: I can't believe myself, the problem is caused by something completely different. I discovered that the problem occurs only under this circumstances: 1. Lines in php.ini file ends by CRLF. 2. Windows Extensions part in php.ini is longer than 503 characters (including new-lines). I don't know what is it but it looks like buffer overflow or something like that. So the problem is probably in php-src/main/php_ini.c or somewhere near. Previous Comments: [2003-12-02 10:22:37] nunoplopes at sapo dot pt This bug is solved! I have the latest windows snapshot on windows xp and cli returns a random value without the need to use srand. [2003-11-28 04:26:47] spam at vrana dot cz The behavior of rand() really changed in PHP 4.2.0, it is stated in Changelog. The documentation is correct. And there is coded this feature in source codes (php-src/ext/standard/rand.c, line 327 in current CVS). I don't know where the problem is, I don't understand PHP internals. I can only see that there is global variable rand_is_seeded set on line 58 and checked on line 326. Maybe the problem is that this variable wasn't initialized. I'm just guessing because as I wrote, I don't understand PHP internals. [2003-11-25 08:57:29] [EMAIL PROTECTED] Manual is wrong. [2003-11-25 08:46:41] spam at vrana dot cz iliaa, please read the manual yourself before stating bugs as bogus. As I already wrote here, the manual says: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically. [2003-11-25 08:41:49] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php For random numbers you MUST call srand() before rand(). 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Fbk-Opn]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP -PHP Version: 4.3.3 +PHP Version: 4.3.5-dev New Comment: Yes. The problem occurs also with CVS snapshot. Previous Comments: [2003-12-02 11:04:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-12-02 10:57:15] spam at vrana dot cz I can't believe myself, the problem is caused by something completely different. I discovered that the problem occurs only under this circumstances: 1. Lines in php.ini file ends by CRLF. 2. Windows Extensions part in php.ini is longer than 503 characters (including new-lines). I don't know what is it but it looks like buffer overflow or something like that. So the problem is probably in php-src/main/php_ini.c or somewhere near. [2003-12-02 10:22:37] nunoplopes at sapo dot pt This bug is solved! I have the latest windows snapshot on windows xp and cli returns a random value without the need to use srand. [2003-11-28 04:26:47] spam at vrana dot cz The behavior of rand() really changed in PHP 4.2.0, it is stated in Changelog. The documentation is correct. And there is coded this feature in source codes (php-src/ext/standard/rand.c, line 327 in current CVS). I don't know where the problem is, I don't understand PHP internals. I can only see that there is global variable rand_is_seeded set on line 58 and checked on line 326. Maybe the problem is that this variable wasn't initialized. I'm just guessing because as I wrote, I don't understand PHP internals. [2003-11-25 08:57:29] [EMAIL PROTECTED] Manual is wrong. 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Fbk-Opn]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4CVS-2003-12-2 New Comment: Everything is written on http://bugs.php.net/?id=26381. It seems that by some problem in processing php.ini is caused that rand() without srand() doesn't work. It's most probably only side-effect of something wrong (like buffer-overflow). Previous Comments: [2003-12-02 12:51:13] [EMAIL PROTECTED] What problem? How can we reproduce this? [2003-12-02 11:18:28] spam at vrana dot cz Yes. The problem occurs also with CVS snapshot. [2003-12-02 11:04:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-12-02 10:57:15] spam at vrana dot cz I can't believe myself, the problem is caused by something completely different. I discovered that the problem occurs only under this circumstances: 1. Lines in php.ini file ends by CRLF. 2. Windows Extensions part in php.ini is longer than 503 characters (including new-lines). I don't know what is it but it looks like buffer overflow or something like that. So the problem is probably in php-src/main/php_ini.c or somewhere near. [2003-12-02 10:22:37] nunoplopes at sapo dot pt This bug is solved! I have the latest windows snapshot on windows xp and cli returns a random value without the need to use srand. 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Fbk-Opn]: rand() without srand() doesn't work with certain php.ini
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 4CVS-2003-12-2 New Comment: I really don't know which additional information you need. Can you tell me? I described the wrong behaviour on 24 Nov 8:21am EST. I found that the wrong behaviour is most probably bounded with processing of php.ini and described it on 2 Dec 10:57am EST. I tested everything on CVS snapshot on 25 Nov 4:53am EST and on 2 Dec 11:18am EST with the same result. I want to give you all information which you need to fix this bug but I don't know about anything what wasn't already written here. Previous Comments: [2003-12-02 14:28:31] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2003-12-02 13:10:29] spam at vrana dot cz Everything is written on http://bugs.php.net/?id=26381. It seems that by some problem in processing php.ini is caused that rand() without srand() doesn't work. It's most probably only side-effect of something wrong (like buffer-overflow). [2003-12-02 12:51:13] [EMAIL PROTECTED] What problem? How can we reproduce this? [2003-12-02 11:18:28] spam at vrana dot cz Yes. The problem occurs also with CVS snapshot. [2003-12-02 11:04:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Opn]: rand() without srand() doesn't work
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz Status: Open -Bug Type: Documentation problem +Bug Type: Math related Operating System: Windows XP PHP Version: 4.3.3 New Comment: The behavior of rand() really changed in PHP 4.2.0, it is stated in Changelog. The documentation is correct. And there is coded this feature in source codes (php-src/ext/standard/rand.c, line 327 in current CVS). I don't know where the problem is, I don't understand PHP internals. I can only see that there is global variable rand_is_seeded set on line 58 and checked on line 326. Maybe the problem is that this variable wasn't initialized. I'm just guessing because as I wrote, I don't understand PHP internals. Previous Comments: [2003-11-25 08:57:29] [EMAIL PROTECTED] Manual is wrong. [2003-11-25 08:46:41] spam at vrana dot cz iliaa, please read the manual yourself before stating bugs as bogus. As I already wrote here, the manual says: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically. [2003-11-25 08:41:49] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php For random numbers you MUST call srand() before rand(). [2003-11-25 04:53:44] spam at vrana dot cz Unfortunately it behaves the same with Windows snapshots. For case it's not obvious from my fist comment - if I call srand() before rand() it works well. [2003-11-25 04:24:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine for me within Windows XP, within Apache and CLI. 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/26381 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Bgs-Opn]: rand() without srand() doesn't work
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Bogus +Status: Open Bug Type: Math related Operating System: Windows XP PHP Version: 4.3.3 New Comment: So this is a documentation problem because in rand() function documentation is written: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically. Anyway, I think it's not a documentation bug because in other environments it works as stated. Previous Comments: [2003-11-24 20:01:53] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php if you want trully random numbers you MUST call srand before rand(). [2003-11-24 08:21:33] spam at vrana dot cz Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Fbk-Opn]: rand() without srand() doesn't work
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Feedback +Status: Open Bug Type: Math related Operating System: Windows XP PHP Version: 4.3.3 New Comment: Unfortunately it behaves the same with Windows snapshots. For case it's not obvious from my fist comment - if I call srand() before rand() it works well. Previous Comments: [2003-11-25 04:24:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine for me within Windows XP, within Apache and CLI. [2003-11-24 08:21:33] spam at vrana dot cz Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [Bgs-Opn]: rand() without srand() doesn't work
ID: 26381 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Bogus +Status: Open Bug Type: Math related Operating System: Windows XP PHP Version: 4.3.3 New Comment: iliaa, please read the manual yourself before stating bugs as bogus. As I already wrote here, the manual says: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically. Previous Comments: [2003-11-25 08:41:49] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php For random numbers you MUST call srand() before rand(). [2003-11-25 04:53:44] spam at vrana dot cz Unfortunately it behaves the same with Windows snapshots. For case it's not obvious from my fist comment - if I call srand() before rand() it works well. [2003-11-25 04:24:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine for me within Windows XP, within Apache and CLI. [2003-11-24 08:21:33] spam at vrana dot cz Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit this bug report at http://bugs.php.net/?id=26381edit=1
#26381 [NEW]: rand() without srand() doesn't work
From: spam at vrana dot cz Operating system: Windows XP PHP version: 4.3.3 PHP Bug Type: Math related Bug description: rand() without srand() doesn't work Description: Function rand() without setting random seed by srand() returns always the same value. It doesn't work only on Windows PHP-CLI. As Windows Apache module and also on Linux PHP-CLI it works as it should. Reproduce code: --- echo rand(); Expected result: (random value) Actual result: -- 24849 -- Edit bug report at http://bugs.php.net/?id=26381edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26381r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26381r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26381r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26381r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26381r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26381r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26381r=support Expected behavior: http://bugs.php.net/fix.php?id=26381r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26381r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26381r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26381r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26381r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26381r=dst IIS Stability: http://bugs.php.net/fix.php?id=26381r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26381r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26381r=float
#26117 [Bgs-Opn]: Persistent connection not reused
ID: 26117 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: Linux PHP Version: 4.3.3 New Comment: Do you think that there is no problem if it works for YOU and doesn't work for others? Previous Comments: [2003-11-18 15:07:14] [EMAIL PROTECTED] Well, it does work fine for me. [2003-11-18 07:33:03] spam at vrana dot cz Can you please read my bug report carefuly before stating bug as bogus? Persistent connection in PHP should reuse previous persistent connection with the same host, user and password. The bug is that it doesn't. [2003-11-17 18:21:48] [EMAIL PROTECTED] And this is PHP bug in where..? [2003-11-05 12:20:11] spam at vrana dot cz Yes. There were 466 processes with the same user, host and db. All processes were in state Sleep. [2003-11-05 11:21:33] [EMAIL PROTECTED] When the too many connections problem occurs, have you tried running show full processlist; query to see if infact all connections use the same database? 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/26117 -- Edit this bug report at http://bugs.php.net/?id=26117edit=1
#26117 [Bgs-Opn]: Persistent connection not reused
ID: 26117 User updated by: spam at vrana dot cz Reported By: spam at vrana dot cz -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: Linux PHP Version: 4.3.3 New Comment: Can you please read my bug report carefuly before stating bug as bogus? Persistent connection in PHP should reuse previous persistent connection with the same host, user and password. The bug is that it doesn't. Previous Comments: [2003-11-17 18:21:48] [EMAIL PROTECTED] And this is PHP bug in where..? [2003-11-05 12:20:11] spam at vrana dot cz Yes. There were 466 processes with the same user, host and db. All processes were in state Sleep. [2003-11-05 11:21:33] [EMAIL PROTECTED] When the too many connections problem occurs, have you tried running show full processlist; query to see if infact all connections use the same database? [2003-11-05 03:24:59] spam at vrana dot cz This is not the case. Believe me that I have read all similar bugs and this is different. I also have read carefuly the manual and I understand everything written there about persistent connections. There is written in the Persistent Database Connections chapter of manual: An 'identical' connection is a connection that was opened to the same host, with the same username and the same password (where applicable). So it's not true that by mysql_select_db() with different database name the connection can't be reused. Anyway I use the same database in all scripts. I know that connection is persistent only over the child. Thus I wrote that Apache configuration directive MaxClients is set to 150. [2003-11-04 13:53:56] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php If you go mysql_select_db() then the persistent connection you've created becomes specific to that particular database. Which may explain why those connections are not re-used. Also, persistent connections are per-child, meaning that if 1 Apache child opens connections only that child has a pre-existing connection avaliable. If a subsequent request is handled by another child, which does not yet have a MySQL connection, it'll create a new connection. 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/26117 -- Edit this bug report at http://bugs.php.net/?id=26117edit=1
#26238 [NEW]: flush() doesn't work with output_buffering = 4096
From: spam at vrana dot cz
Operating system: Windows XP
PHP version: 4.3.3
PHP Bug Type: Output Control
Bug description: flush() doesn't work with output_buffering = 4096
Description:
I have set output_buffering = 4096 and flush(), ob_implicit_flush(),
ob_flush() and similar functions doesn't work. This is reproducible in PHP
Apache module, in PHP-CLI and also on Linux.
Reproduce code:
---
while (true) {
echo .;
flush();
sleep(1);
}
Expected result:
. (1 second) . (1 second) ...
Actual result:
--
nothing (for output_buffering seconds)
--
Edit bug report at http://bugs.php.net/?id=26238edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26238r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26238r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26238r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26238r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26238r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=26238r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26238r=support
Expected behavior: http://bugs.php.net/fix.php?id=26238r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26238r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26238r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26238r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26238r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26238r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26238r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26238r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26238r=float
