#41888 [Com]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 Comment by: hans at velum dot net Reported By: hans at velum dot net Status: No Feedback Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.4 Assigned To: iliaa New Comment: Indeed - this appears to be fixed in latest PHP 5.2.x release. Thanks! Previous Comments: [2009-02-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-02-13 22:13:02] fel...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-01-14 20:53:04] hans at velum dot net Any idea when this issue might get fixed? This is a big deal to us, since this bug prevents us from swapping out filesystem-based storage with a db-storage engine. [2007-10-01 20:04:40] hans at velum dot net Updating version to reflect that problem is still present in 5.2.4 [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d 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/41888 -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#44433 [NEW]: Text with null characters (\0) truncated when bound to prepared statement
From: hans at velum dot net
Operating system: Gentoo Linux
PHP version: 5.2.5
PHP Bug Type: PDO related
Bug description: Text with null characters (\0) truncated when bound to
prepared statement
Description:
I'm using PostgreSQL (8.2.x) and am having a problem inserting serialized
data containing null characters (\0) into the database. I am using
prepared statements and the bindValue() method to bind the serialized data
as a PDO::PARAM_STR.
It's not obvious from the output below, but these serialized strings
contain null values because of the private variables.
I can't seem to find an existing bug for this; however, it surprises me
that no one has reported this before.
Reproduce code:
---
$pdo = new PDO('pgsql: dbname=testdb user=postgres');
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try {
$pdo-exec('DROP TABLE testtbl');
} catch (PDOException $x) { /* ignore */ }
$pdo-exec('CREATE TABLE testtbl (id integer not null, txtcol text)');
class MyClass {
private $var1;
function __construct($val) { $this-var1 = $val; }
}
$serialized = serialize(array('foo' = new MyClass('bar'), 'baz' = new
MyClass('bingo!')));
print Serialized data: . $serialized . PHP_EOL;
$stmt = $pdo-prepare('INSERT INTO testtbl (id, txtcol) VALUES (1, ?)');
$stmt-bindValue(1, $serialized, PDO::PARAM_STR);
$stmt-execute();
$stmt = $pdo-query('SELECT * FROM testtbl WHERE id = 1');
$row = $stmt-fetch();
print From database: . $row['txtcol'] . PHP_EOL;
Expected result:
Serialized data:
a:2:{s:3:foo;O:7:MyClass:1:{s:13:MyClassvar1;s:3:bar;}s:3:baz;O:7:MyClass:1:{s:13:MyClassvar1;s:6:bingo!;}}
From database:
a:2:{s:3:foo;O:7:MyClass:1:{s:13:MyClassvar1;s:3:bar;}s:3:baz;O:7:MyClass:1:{s:13:MyClassvar1;s:6:bingo!;}}
Actual result:
--
Serialized data:
a:2:{s:3:foo;O:7:MyClass:1:{s:13:MyClassvar1;s:3:bar;}s:3:baz;O:7:MyClass:1:{s:13:MyClassvar1;s:6:bingo!;}}
From database: a:2:{s:3:foo;O:7:MyClass:1:{s:13:
--
Edit bug report at http://bugs.php.net/?id=44433edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44433r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44433r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44433r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44433r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44433r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44433r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44433r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44433r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44433r=support
Expected behavior:http://bugs.php.net/fix.php?id=44433r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44433r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44433r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44433r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44433r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44433r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44433r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44433r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44433r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44433r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44433r=mysqlcfg
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.4 Assigned To: iliaa New Comment: Any idea when this issue might get fixed? This is a big deal to us, since this bug prevents us from swapping out filesystem-based storage with a db-storage engine. Previous Comments: [2007-10-01 20:04:40] hans at velum dot net Updating version to reflect that problem is still present in 5.2.4 [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! [2007-09-06 13:36:53] hans at velum dot net Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#43302 [Opn-Bgs]: Type hints do not respect imported namespaces
ID: 43302
User updated by: hans at velum dot net
Reported By: hans at velum dot net
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Gentoo
PHP Version: 5.3CVS-2007-11-15 (snap)
New Comment:
Ok, I think I see my error :) I was assuming that use proj::a; would
bring the classes within that namespace into my local scope, but clearly
that is not the case. Thanks for clarification. I could have sworn
that I had an example where that did work ... but if I did, I'll open
another bug to discuss the inconsistency :)
Previous Comments:
[2007-11-15 09:43:09] felipensp at gmail dot com
This is expected.
README.namespaces:
7) qualified class names are interpreted as class from corresponding
namespace. So new A::B::C() refers to class C from namespace A::B.
...
?php
namespace A;
new A(); // first tries to create object of class A from namespace
A (A::A)
// then creates object of internal class A
?
Using:
use proj::a; with type hint a::AClass.
or
without 'use' with type hint proj::a::AClass.
or
use proj::a as x; with type hint x::AClass.
Works fine!
[2007-11-15 02:27:33] hans at velum dot net
Description:
When using type hints, the namespaces that were imported (using use)
are not consulted to resolve the type-hinted class names. i.e. if I
have a class defined in namespace foo::bar, it is assumed that *all*
classes specified as type hints used in methods in my class are in the
foo::bar namespace -- regardless of which other namespaces I import.
Reproduce code:
---
This is best illustrated with 3 files:
AClass.php:
?php
namespace proj::a;
class AClass {}
?
BClass.php:
?php
namespace proj::b;
use proj::a;
class BClass {
function setA(AClass $a) {}
}
?
test.php:
?php
require 'AClass.php';
require 'BClass.php';
$b = new proj::b::BClass();
$b-setA(new proj::a::AClass());
?
Expected result:
No error.
Actual result:
--
Catchable fatal error: Argument 1 passed to proj::b::BClass::setA()
must be an instance of proj::b::AClass, instance of proj::a::AClass
given, called in test.php on line 6 and defined in BClass.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=43302edit=1
#43302 [NEW]: Type hints do not respect imported namespaces
From: hans at velum dot net
Operating system: Gentoo
PHP version: 5.3CVS-2007-11-15 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Type hints do not respect imported namespaces
Description:
When using type hints, the namespaces that were imported (using use) are
not consulted to resolve the type-hinted class names. i.e. if I have a
class defined in namespace foo::bar, it is assumed that *all* classes
specified as type hints used in methods in my class are in the foo::bar
namespace -- regardless of which other namespaces I import.
Reproduce code:
---
This is best illustrated with 3 files:
AClass.php:
?php
namespace proj::a;
class AClass {}
?
BClass.php:
?php
namespace proj::b;
use proj::a;
class BClass {
function setA(AClass $a) {}
}
?
test.php:
?php
require 'AClass.php';
require 'BClass.php';
$b = new proj::b::BClass();
$b-setA(new proj::a::AClass());
?
Expected result:
No error.
Actual result:
--
Catchable fatal error: Argument 1 passed to proj::b::BClass::setA() must
be an instance of proj::b::AClass, instance of proj::a::AClass given,
called in test.php on line 6 and defined in BClass.php on line 5
--
Edit bug report at http://bugs.php.net/?id=43302edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43302r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43302r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43302r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43302r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43302r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43302r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43302r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43302r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43302r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43302r=support
Expected behavior:http://bugs.php.net/fix.php?id=43302r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43302r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43302r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43302r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43302r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43302r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43302r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43302r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43302r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43302r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43302r=mysqlcfg
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux -PHP Version: 5.2.3 +PHP Version: 5.2.4 Assigned To: iliaa New Comment: Updating version to reflect that problem is still present in 5.2.4 Previous Comments: [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! [2007-09-06 13:36:53] hans at velum dot net Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.3 Assigned To: iliaa New Comment: Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. Previous Comments: [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.3 Assigned To: iliaa New Comment: Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! Previous Comments: [2007-09-06 13:36:53] hans at velum dot net Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#41888 [NEW]: Segfault when attempting to update PDO LOB column in a stream wrapper
From: hans at velum dot net Operating system: Gentoo Linux PHP version: 5.2.3 PHP Bug Type: PDO related Bug description: Segfault when attempting to update PDO LOB column in a stream wrapper Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit bug report at http://bugs.php.net/?id=41888edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41888r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41888r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41888r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41888r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41888r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41888r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41888r=needscript Try newer version:http://bugs.php.net/fix.php?id=41888r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41888r=support Expected behavior:http://bugs.php.net/fix.php?id=41888r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41888r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41888r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41888r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41888r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41888r=dst IIS Stability:http://bugs.php.net/fix.php?id=41888r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41888r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41888r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41888r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41888r=mysqlcfg
#40913 [Com]: PDO::PARAM_LOB does not bind to a stream for fetching a BLOB
ID: 40913
Comment by: hans at velum dot net
Reported By: dennis at inmarket dot lviv dot ua
Status: Assigned
Bug Type: PDO related
Operating System: Win XP
PHP Version: 5.2.1
Assigned To: wez
New Comment:
I believe this is probably the same issue, but I also notice that using
MySQL to simply execute a SQL query which contains BLOB result columns
is also returning strings instead of streams. The difference being that
I'm not using bindColumn() and specifying PDO::PARAM_LOB. I wouldn't
expect that I'd need to, since simply performing a standard fetch()
works as expected w/ Postgres (and, I believe, Oracle).
Previous Comments:
[2007-03-25 12:29:07] dennis at inmarket dot lviv dot ua
Description:
PDOStatement::bindColumn($idx, $var, PDO::PARAM_LOB) for SELECT query
makes $var a string with the BLOB Data rather than a stream, for both
MySQL and SQLite.
Reproduce code:
---
$id = (int)$_REQUEST['book'];
$stmt = $conn-prepare(SELECT coverMime, coverImage FROM books WHERE
id=$id);
$stmt-execute();
$stmt-bindColumn(1, $mime);
$stmt-bindColumn(2, $image, PDO::PARAM_LOB);
$stmt-fetch(PDO::FETCH_BOUND);
var_dump($image);
Expected result:
Resource #1
Actual result:
--
String(792) {GIF89a...}
--
Edit this bug report at http://bugs.php.net/?id=40913edit=1
#40691 [Asn]: Incorrect results of DateTime equality check
ID: 40691 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: Date/time related Operating System: Gentoo Linux PHP Version: 5.2.1 Assigned To: derick New Comment: Thanks, Derick! Previous Comments: [2007-03-05 09:59:48] [EMAIL PROTECTED] I am not sure it is even possible to overload the == operator here, but I can check that. However, the comparison of unix timestamps is still the way to go for now. [2007-03-04 20:40:49] hans at velum dot net I maintain that this is counter-intuitive behavior. Do any other built-in classes have this same comparison feature where they always return TRUE when checked for eqaulity? If you truly believe this is bogus, then this is a problem that must be addressed in the documenation (which incidentally is basically horrible for the DateTime class). It is simply not acceptable behavior to have a == comparison between ANY DateTime object return TRUE. This type of inconsistent incoherent behavior in the PHP core is why PHP maintains a poor reputation for OO development. It would be a huge help to the community if these core classes worked in a predictable manner, or at *least* if their unpredictable behavior were addressed by documentation. [2007-03-04 18:34:12] [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 This is not a bug. The date extension does not provide (or is intended) for the purpose of comparing two date objects. You could have the same date in the object by different properties initialized due to the way the object was created. As I've said earlier the most reliable way to compare two dates would be to convert them to unix timestamps and then compare the two. [2007-03-03 21:36:07] dzuelke at gmail dot com hans at velum dot net is correct, I just stumbled over the same issue. It definitely smells like a bug, nothing bogus here. The stored date is a property of the object, but not compared properly as it should according to the rules described at http://php.net/manual/en/ language.oop5.php. Probably because it's not possible to pull the individual parts of a date (day, month, year etc) from a DateTime instance, but that's a different story... [2007-03-03 19:47:15] hans at velum dot net This is not bogus. Maybe won't fix but definitely not bogus. Please note that I am quite familiar with object comparison in PHP. The documenation says: When using the comparison operator (==), object variables are compared in a simple manner, namely: Two object instances are equal if they have the same attributes and values, and are instances of the same class. Indeed, AS I POINTED OUT IN THE DESCRIPTION, other built-in objects in PHP demonstrate the correct/expected behavior: $a = new Exception(foo); $b = new Exception(bar); $c = new Exception(foo); var_export($a == $b); // Outputs: FALSE var_export($a == $c); // Outputs: TRUE A DateTime object have very obvious properties (namely the date/time value contained, possibly time zone of other info specified). The equality check (NOT IDENTITY CHECK) should be comparing those values, as apparently it does for Exception. 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/40691 -- Edit this bug report at http://bugs.php.net/?id=40691edit=1
#40691 [Bgs-Opn]: Incorrect results of DateTime equality check
ID: 40691 User updated by: hans at velum dot net Reported By: hans at velum dot net -Status: Bogus +Status: Open Bug Type: Date/time related Operating System: Gentoo Linux PHP Version: 5.2.1 New Comment: I maintain that this is counter-intuitive behavior. Do any other built-in classes have this same comparison feature where they always return TRUE when checked for eqaulity? If you truly believe this is bogus, then this is a problem that must be addressed in the documenation (which incidentally is basically horrible for the DateTime class). It is simply not acceptable behavior to have a == comparison between ANY DateTime object return TRUE. This type of inconsistent incoherent behavior in the PHP core is why PHP maintains a poor reputation for OO development. It would be a huge help to the community if these core classes worked in a predictable manner, or at *least* if their unpredictable behavior were addressed by documentation. Previous Comments: [2007-03-04 18:34:12] [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 This is not a bug. The date extension does not provide (or is intended) for the purpose of comparing two date objects. You could have the same date in the object by different properties initialized due to the way the object was created. As I've said earlier the most reliable way to compare two dates would be to convert them to unix timestamps and then compare the two. [2007-03-03 21:36:07] dzuelke at gmail dot com hans at velum dot net is correct, I just stumbled over the same issue. It definitely smells like a bug, nothing bogus here. The stored date is a property of the object, but not compared properly as it should according to the rules described at http://php.net/manual/en/ language.oop5.php. Probably because it's not possible to pull the individual parts of a date (day, month, year etc) from a DateTime instance, but that's a different story... [2007-03-03 19:47:15] hans at velum dot net This is not bogus. Maybe won't fix but definitely not bogus. Please note that I am quite familiar with object comparison in PHP. The documenation says: When using the comparison operator (==), object variables are compared in a simple manner, namely: Two object instances are equal if they have the same attributes and values, and are instances of the same class. Indeed, AS I POINTED OUT IN THE DESCRIPTION, other built-in objects in PHP demonstrate the correct/expected behavior: $a = new Exception(foo); $b = new Exception(bar); $c = new Exception(foo); var_export($a == $b); // Outputs: FALSE var_export($a == $c); // Outputs: TRUE A DateTime object have very obvious properties (namely the date/time value contained, possibly time zone of other info specified). The equality check (NOT IDENTITY CHECK) should be comparing those values, as apparently it does for Exception. [2007-03-03 15:55:40] [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 Read on object comparison in PHP, what you are attempting will not work. if you want to compare 2 dates, convert them to unix timestamps first. [2007-03-02 15:43:14] hans at velum dot net Description: The equality check (==) for DateTime objects does not actually check the properties of the object (i.e. the internally stored date). This is very counter-intuitive as it does not follow the behavior of user-created objects or even other internal PHP objects like Exception. Reproduce code: --- $d1 = new DateTime(2001-01-01); $d2 = new DateTime(2007-02-28); print DateTime Equal? . var_export($d1 == $d2, true) . \n; Expected result: DateTime Equal? false Actual result: -- DateTime Equal? true -- Edit this bug report at http://bugs.php.net/?id=40691edit=1
#40691 [Bgs-Opn]: Incorrect results of DateTime equality check
ID: 40691 User updated by: hans at velum dot net Reported By: hans at velum dot net -Status: Bogus +Status: Open Bug Type: Date/time related Operating System: Gentoo Linux PHP Version: 5.2.1 New Comment: This is not bogus. Maybe won't fix but definitely not bogus. Please note that I am quite familiar with object comparison in PHP. The documenation says: When using the comparison operator (==), object variables are compared in a simple manner, namely: Two object instances are equal if they have the same attributes and values, and are instances of the same class. Indeed, AS I POINTED OUT IN THE DESCRIPTION, other built-in objects in PHP demonstrate the correct/expected behavior: $a = new Exception(foo); $b = new Exception(bar); $c = new Exception(foo); var_export($a == $b); // Outputs: FALSE var_export($a == $c); // Outputs: TRUE A DateTime object have very obvious properties (namely the date/time value contained, possibly time zone of other info specified). The equality check (NOT IDENTITY CHECK) should be comparing those values, as apparently it does for Exception. Previous Comments: [2007-03-03 15:55:40] [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 Read on object comparison in PHP, what you are attempting will not work. if you want to compare 2 dates, convert them to unix timestamps first. [2007-03-02 15:43:14] hans at velum dot net Description: The equality check (==) for DateTime objects does not actually check the properties of the object (i.e. the internally stored date). This is very counter-intuitive as it does not follow the behavior of user-created objects or even other internal PHP objects like Exception. Reproduce code: --- $d1 = new DateTime(2001-01-01); $d2 = new DateTime(2007-02-28); print DateTime Equal? . var_export($d1 == $d2, true) . \n; Expected result: DateTime Equal? false Actual result: -- DateTime Equal? true -- Edit this bug report at http://bugs.php.net/?id=40691edit=1
#40691 [NEW]: Incorrect results of DateTime equality check
From: hans at velum dot net Operating system: Gentoo Linux PHP version: 5.2.1 PHP Bug Type: Date/time related Bug description: Incorrect results of DateTime equality check Description: The equality check (==) for DateTime objects does not actually check the properties of the object (i.e. the internally stored date). This is very counter-intuitive as it does not follow the behavior of user-created objects or even other internal PHP objects like Exception. Reproduce code: --- $d1 = new DateTime(2001-01-01); $d2 = new DateTime(2007-02-28); print DateTime Equal? . var_export($d1 == $d2, true) . \n; Expected result: DateTime Equal? false Actual result: -- DateTime Equal? true -- Edit bug report at http://bugs.php.net/?id=40691edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40691r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40691r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40691r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40691r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40691r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40691r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40691r=needscript Try newer version:http://bugs.php.net/fix.php?id=40691r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40691r=support Expected behavior:http://bugs.php.net/fix.php?id=40691r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40691r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40691r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40691r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40691r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40691r=dst IIS Stability:http://bugs.php.net/fix.php?id=40691r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40691r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40691r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40691r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40691r=mysqlcfg
#38546 [Com]: bindParam incorrect processing of bool types
ID: 38546
Comment by: hans at velum dot net
Reported By: selecter at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Gentoo Linux x86_64
PHP Version: latest snapshot
Assigned To: wez
New Comment:
I don't think that anyone said this was crashing. It certainly is a
fatal error in that it doesn't work. And using PDO w/ Exception error
mode will (should!) eventually result in a fatal error for the app
that's using it.
This is clearly a PDO bug. If any application that uses PDO has to
check to see if MySQL is being used then alter that type params
passed to bindValue() then there is NO VALUE in having the small set of
*abstracted* types that PDO does provide.
Previous Comments:
[2006-08-22 16:59:46] [EMAIL PROTECTED]
First of all, there is no crash.
Fatal error is the result of your trigger_error() call.
PDOStatement::execute() fails because MySQL API doesn't support boolean
parameters (though they can be emulated through PDO).
I'm leaving this to the maintainer to decide.
[2006-08-22 16:42:10] selecter at gmail dot com
That's what you get: Fatal error: : in /tmp/1.php on line 66
That's all that matters...
Instead of:
'show_email' = (bool) 1,
'show_smiles' = (bool) 1,
Write:
'show_email' = 1,
'show_smiles' = 1,
and the query will be executed successfully.
[2006-08-22 16:29:14] [EMAIL PROTECTED]
I get:
---
array(1) {
[0]=
string(5) 0
}
Notice: Undefined property: PDO::$errorCode in /tmp/1.php on line 62
Notice: Undefined offset: 2 in /tmp/1.php on line 62
pre/pre
Fatal error: : in /tmp/1.php on line 66
---
No crashes. valgrind doesn't show anything wrong there.
[2006-08-22 15:54:30] selecter at gmail dot com
Still reproducable. Here's the code:
?php
try{
$dsn = 'mysql:host=localhost;dbname=test';
$db = new PDO($dsn, 'root', 'pass');
}catch(PDOException $e){
trigger_error($e-getMessage(), E_USER_ERROR);
}
$prefs = array(
'show_email' = (bool) 1,
'show_smiles' = (bool) 1,
'timezone_offset' = 0,
'messages_on_page' = 5,
'uid', 6
);
$query = CREATE TABLE prefs(
uid MEDIUMINT UNSIGNED NOT NULL,
show_email BOOL NOT NULL,
show_smiles BOOL NOT NULL,
timezone_offset TINYINT NOT NULL,
messages_on_page TINYINT UNSIGNED NOT NULL
);
$query = INSERT INTO prefs VALUES(6, 1, 1, 0, 5);
$db-exec($query);
$st = $db-prepare(UPDATE prefs SET show_email=?,
show_smiles=?,
timezone_offset=?, messages_on_page=? WHERE uid=?);
$st-bindParam(1, $prefs['show_email'], PDO::PARAM_BOOL);
$st-bindParam(2, $prefs['show_smiles'], PDO::PARAM_BOOL);
$st-bindParam(3, $prefs['timezone_offset'], PDO::PARAM_INT);
$st-bindParam(4, $prefs['messages_on_page'], PDO::PARAM_INT);
$id = 6;
$st-bindParam(5, $id, PDO::PARAM_INT);
if(($num=$st-execute()) === FALSE){
$einfo = $db-errorInfo();
$einfo = $db-errorCode.': '.$einfo[2];
?pre?php
debug_print_backtrace();
?/pre?php
trigger_error($einfo, E_USER_ERROR);
}else{
echo 'ok';
}
?
[2006-08-22 15:13:16] [EMAIL PROTECTED]
If you're still able to reproduce it with the latest 5.2 snapshot
(several changes were applied yesterday), please provide SHORT and
COMPLETE reproduce script (complete means no missing tables, no
missing variables etc.).
A gdb backtrace would be also helpful.
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/38546
--
Edit this bug report at http://bugs.php.net/?id=38546edit=1
#38546 [Com]: bindParam incorrect processing of bool types
ID: 38546
Comment by: hans at velum dot net
Reported By: selecter at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Gentoo Linux x86_64
PHP Version: latest snapshot
Assigned To: wez
New Comment:
This looks to be the same issue as:
http://pecl.php.net/bugs/bug.php?id=9919
Previous Comments:
[2007-02-06 16:35:47] hans at velum dot net
I don't think that anyone said this was crashing. It certainly is a
fatal error in that it doesn't work. And using PDO w/ Exception error
mode will (should!) eventually result in a fatal error for the app
that's using it.
This is clearly a PDO bug. If any application that uses PDO has to
check to see if MySQL is being used then alter that type params
passed to bindValue() then there is NO VALUE in having the small set of
*abstracted* types that PDO does provide.
[2006-08-22 16:59:46] [EMAIL PROTECTED]
First of all, there is no crash.
Fatal error is the result of your trigger_error() call.
PDOStatement::execute() fails because MySQL API doesn't support boolean
parameters (though they can be emulated through PDO).
I'm leaving this to the maintainer to decide.
[2006-08-22 16:42:10] selecter at gmail dot com
That's what you get: Fatal error: : in /tmp/1.php on line 66
That's all that matters...
Instead of:
'show_email' = (bool) 1,
'show_smiles' = (bool) 1,
Write:
'show_email' = 1,
'show_smiles' = 1,
and the query will be executed successfully.
[2006-08-22 16:29:14] [EMAIL PROTECTED]
I get:
---
array(1) {
[0]=
string(5) 0
}
Notice: Undefined property: PDO::$errorCode in /tmp/1.php on line 62
Notice: Undefined offset: 2 in /tmp/1.php on line 62
pre/pre
Fatal error: : in /tmp/1.php on line 66
---
No crashes. valgrind doesn't show anything wrong there.
[2006-08-22 15:54:30] selecter at gmail dot com
Still reproducable. Here's the code:
?php
try{
$dsn = 'mysql:host=localhost;dbname=test';
$db = new PDO($dsn, 'root', 'pass');
}catch(PDOException $e){
trigger_error($e-getMessage(), E_USER_ERROR);
}
$prefs = array(
'show_email' = (bool) 1,
'show_smiles' = (bool) 1,
'timezone_offset' = 0,
'messages_on_page' = 5,
'uid', 6
);
$query = CREATE TABLE prefs(
uid MEDIUMINT UNSIGNED NOT NULL,
show_email BOOL NOT NULL,
show_smiles BOOL NOT NULL,
timezone_offset TINYINT NOT NULL,
messages_on_page TINYINT UNSIGNED NOT NULL
);
$query = INSERT INTO prefs VALUES(6, 1, 1, 0, 5);
$db-exec($query);
$st = $db-prepare(UPDATE prefs SET show_email=?,
show_smiles=?,
timezone_offset=?, messages_on_page=? WHERE uid=?);
$st-bindParam(1, $prefs['show_email'], PDO::PARAM_BOOL);
$st-bindParam(2, $prefs['show_smiles'], PDO::PARAM_BOOL);
$st-bindParam(3, $prefs['timezone_offset'], PDO::PARAM_INT);
$st-bindParam(4, $prefs['messages_on_page'], PDO::PARAM_INT);
$id = 6;
$st-bindParam(5, $id, PDO::PARAM_INT);
if(($num=$st-execute()) === FALSE){
$einfo = $db-errorInfo();
$einfo = $db-errorCode.': '.$einfo[2];
?pre?php
debug_print_backtrace();
?/pre?php
trigger_error($einfo, E_USER_ERROR);
}else{
echo 'ok';
}
?
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/38546
--
Edit this bug report at http://bugs.php.net/?id=38546edit=1
#35777 [NEW]: syslog() logs garbage
From: hans at velum dot net Operating system: PHP version: 5.1.1 PHP Bug Type: Unknown/Other Function Bug description: syslog() logs garbage Description: Bug #28722 still seems to be a bug -- and there is apparently no way to re-open or comment on a bug that was marked Bogus prematurely. We see this problem using PHP 5.0.5. I assume that it's still an issue for 5.1.1, but I don't have the luxury of running that branch yet. * We _are_ using syslog logging from our PHP application * We have php errors going to syslog (in php.ini error_log is set to 'syslog') * We _always_ call openlog() before any syslog() calls in the PHP application. We see garbage in the syslog when PHP errors (e.g. PHP Fatal Error...) are sent to syslog *without* our application having sent any logs (and hence without having called openlog()). The workaround is to always call openlog() in our PHP application regardless of whether the application actually needs to call syslog() itself. -- Edit bug report at http://bugs.php.net/?id=35777edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35777r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35777r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35777r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35777r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35777r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35777r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35777r=needscript Try newer version:http://bugs.php.net/fix.php?id=35777r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35777r=support Expected behavior:http://bugs.php.net/fix.php?id=35777r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35777r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35777r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35777r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35777r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35777r=dst IIS Stability:http://bugs.php.net/fix.php?id=35777r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35777r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35777r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35777r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35777r=mysqlcfg
#30527 [Com]: magic_quotes_gpc does not work per-directory
ID: 30527 Comment by: hans at velum dot net Reported By: andrew at crannog-software dot com Status: No Feedback Bug Type: PHP options/info functions Operating System: Windows 2000 PHP Version: 4.3.9 New Comment: This bug is still happening as of 4.3.11 and is a pretty serious impediment to deploying complex PHP applications in IIS. Previous Comments: [2005-02-11 01:00:35] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-02-03 04:47:57] [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 [2004-12-02 09:42:25] andrew at crannog-software dot com The problem occurs when using PHP as an ISAPI module. [2004-11-29 19:23:07] hans at velum dot net For me the issue appears when using PHP as ISAPI module w/ IIS. [2004-11-24 16:23:12] [EMAIL PROTECTED] See also bug #30813 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/30527 -- Edit this bug report at http://bugs.php.net/?id=30527edit=1
#29935 [Com]: array_filter crashes Apache 2
ID: 29935
Comment by: hans at velum dot net
Reported By: webmaster at martialartsmovies dot net
Status: No Feedback
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.0.1
New Comment:
I am also getting segfaults using array_filter on Apache 2 (on Gentoo
Linux).
My backtrace looks like:
#0 0x4070246e in zif_array_filter () from
/etc/apache/modules/libphp5.so
#1 0xbfff3f0c in ?? ()
#2 0xbfff3f10 in ?? ()
#3 0xbfff3f14 in ?? ()
I'm not sure what more I can get from that backtrace.
My array filter code looks like:
$discs =
array_filter(Bb_DiscussionPeer::doSelectUnreadForUserByClique($cliqueId,
$uid), array($this, 'hasPerms'));
Where the first param to array_filter is an array of objects
(verified). And the hasPerms method is a method in parent class that
looks like this:
protected function hasPerms($obj) {
return ($obj-canUser(Perms::READ));
}
(Changing that to be a 'public' method doesn't help.)
I can't seem to narrow down the bug any more than that. It doesn't
seem to happen *all* the time either, but if I have two such similar
calls on a page it will segfault. Sometimes it will segfault if
there's only one, but sometimes it works without segfaulting.
Previous Comments:
[2004-09-17 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-09-02 08:17:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Your code works fine for me, please try a snapshot.
[2004-09-01 20:10:27] webmaster at martialartsmovies dot net
Description:
I have PHP 5.0.1 installed together with the latest stable Apache 2 on
Windows XP SP2. I used the example on the array_filter page on php.net
an all I got was a window telling me that apache caused a problem and
it needed to reboot.
Reproduce code:
---
?php
function odd($var)
{
return($var % 2 == 1);
}
function even($var)
{
return($var % 2 == 0);
}
$array1 = array(a=1, b=2, c=3, d=4, e=5);
$array2 = array(6, 7, 8, 9, 10, 11, 12);
echo Odd :\n;
print_r(array_filter($array1, odd));
echo Even:\n;
print_r(array_filter($array2, even));
?
Expected result:
the array_filter function applied to the 2 arrays
Actual result:
--
apache 2 crashed.
error.log:
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Child process is
running
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Acquired the start
mutex.
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Starting 250 worker
threads.
[Wed Sep 01 19:50:15 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=29935edit=1
#29935 [Com]: array_filter crashes Apache 2
ID: 29935
Comment by: hans at velum dot net
Reported By: webmaster at martialartsmovies dot net
Status: No Feedback
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.0.1
New Comment:
FYI, I'm using PHP 5.0.4.
Previous Comments:
[2005-05-06 17:22:48] hans at velum dot net
I am also getting segfaults using array_filter on Apache 2 (on Gentoo
Linux).
My backtrace looks like:
#0 0x4070246e in zif_array_filter () from
/etc/apache/modules/libphp5.so
#1 0xbfff3f0c in ?? ()
#2 0xbfff3f10 in ?? ()
#3 0xbfff3f14 in ?? ()
I'm not sure what more I can get from that backtrace.
My array filter code looks like:
$discs =
array_filter(Bb_DiscussionPeer::doSelectUnreadForUserByClique($cliqueId,
$uid), array($this, 'hasPerms'));
Where the first param to array_filter is an array of objects
(verified). And the hasPerms method is a method in parent class that
looks like this:
protected function hasPerms($obj) {
return ($obj-canUser(Perms::READ));
}
(Changing that to be a 'public' method doesn't help.)
I can't seem to narrow down the bug any more than that. It doesn't
seem to happen *all* the time either, but if I have two such similar
calls on a page it will segfault. Sometimes it will segfault if
there's only one, but sometimes it works without segfaulting.
[2004-09-17 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-09-02 08:17:57] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
Your code works fine for me, please try a snapshot.
[2004-09-01 20:10:27] webmaster at martialartsmovies dot net
Description:
I have PHP 5.0.1 installed together with the latest stable Apache 2 on
Windows XP SP2. I used the example on the array_filter page on php.net
an all I got was a window telling me that apache caused a problem and
it needed to reboot.
Reproduce code:
---
?php
function odd($var)
{
return($var % 2 == 1);
}
function even($var)
{
return($var % 2 == 0);
}
$array1 = array(a=1, b=2, c=3, d=4, e=5);
$array2 = array(6, 7, 8, 9, 10, 11, 12);
echo Odd :\n;
print_r(array_filter($array1, odd));
echo Even:\n;
print_r(array_filter($array2, even));
?
Expected result:
the array_filter function applied to the 2 arrays
Actual result:
--
apache 2 crashed.
error.log:
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Child process is
running
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Acquired the start
mutex.
[Wed Sep 01 19:47:14 2004] [notice] Child 2412: Starting 250 worker
threads.
[Wed Sep 01 19:50:15 2004] [notice] Parent: child process exited with
status 3221225477 -- Restarting.
--
Edit this bug report at http://bugs.php.net/?id=29935edit=1
#30527 [Com]: magic_quotes_gpc does not work per-directory
ID: 30527 Comment by: hans at velum dot net Reported By: andrew at crannog-software dot com Status: Feedback Bug Type: PHP options/info functions Operating System: Windows 2000 PHP Version: 4.3.9 New Comment: For me the issue appears when using PHP as ISAPI module w/ IIS. Previous Comments: [2004-11-24 16:23:12] [EMAIL PROTECTED] See also bug #30813 [2004-11-24 00:47:53] [EMAIL PROTECTED] Using PHP as CGI binary or ISAPI module? [2004-11-21 18:42:39] hans at velum dot net I can confirm this on Windows 2003 w/ IIS 6 also. Note that the magic_quotes_sybase INI setting is also being ignored. Basically it's always doing magic_quotes_gpc -- despite the phpinfo() / ini_get showing the desired per-directory values. [2004-10-22 11:43:25] andrew at crannog-software dot com Description: When magic_quotes_gpc is controlled per-directory through the registry, the return code from get_magic_quotes_gpc() reflects the change, but the contents of $_GET, $_POST and $_COOKIE remain escaped or not escaped according to the setting in php.ini. The code below was run with magic_quotes_gpc=on in php.ini and magic_quotes_gpc=0 in the registry for the folder in which the script resides. Reproduce code: --- html body magic_quotes_gpc is ?php echo get_magic_quotes_gpc() ? on : off; ?br / text: ?php echo $_REQUEST['text']; ?br / form action=test.php input name=text /nbsp;input type=submit / /form /body /html Expected result: magic_quotes_gpc is off text: test Actual result: -- magic_quotes_gpc is off text: \test\ -- Edit this bug report at http://bugs.php.net/?id=30527edit=1
#30527 [Com]: magic_quotes_gpc does not work per-directory
ID: 30527 Comment by: hans at velum dot net Reported By: andrew at crannog-software dot com Status: Open Bug Type: PHP options/info functions Operating System: Windows 2000 PHP Version: 4.3.9 New Comment: I can confirm this on Windows 2003 w/ IIS 6 also. Note that the magic_quotes_sybase INI setting is also being ignored. Basically it's always doing magic_quotes_gpc -- despite the phpinfo() / ini_get showing the desired per-directory values. Previous Comments: [2004-10-22 11:43:25] andrew at crannog-software dot com Description: When magic_quotes_gpc is controlled per-directory through the registry, the return code from get_magic_quotes_gpc() reflects the change, but the contents of $_GET, $_POST and $_COOKIE remain escaped or not escaped according to the setting in php.ini. The code below was run with magic_quotes_gpc=on in php.ini and magic_quotes_gpc=0 in the registry for the folder in which the script resides. Reproduce code: --- html body magic_quotes_gpc is ?php echo get_magic_quotes_gpc() ? on : off; ?br / text: ?php echo $_REQUEST['text']; ?br / form action=test.php input name=text /nbsp;input type=submit / /form /body /html Expected result: magic_quotes_gpc is off text: test Actual result: -- magic_quotes_gpc is off text: \test\ -- Edit this bug report at http://bugs.php.net/?id=30527edit=1
#29736 [NEW]: instanceof requires class to be loaded
From: hans at velum dot net
Operating system: All
PHP version: 5.0.1
PHP Bug Type: Feature/Change Request
Bug description: instanceof requires class to be loaded
Description:
[pasted from messages on internals@ list]
I like the new $obj instanceof ClassName way of checking class / interface
types, but this method does have one major drawback compared to the
old is_a() approach:
The class must be loaded in order to perform an instanceof check!
There are many situations where you do not want to have to load every
class to see whether a returned object is a class of that type. In
particular for driver classes, the current model requires loading *every*
possible driver in order to check to see which type of class was
returned.
is_a() works great, but has been deprecated and is now generating E_STRICT
errors.
Reproduce code:
---
[conributed by Sean Coates on internals@ list]
?php
class Foo {}
$foo = unserialize('O:3:Foo:0:{}');
echo '$foo is_a Foo? '. (is_a($foo, 'Foo') ? 'yes' : 'no') .\n;
echo '$foo instanceof Foo? '. ($foo instanceof Foo ? 'yes' : 'no') .\n;
?
and
?php
//class Foo {}
$foo = unserialize('O:3:Foo:0:{}');
echo '$foo is_a Foo? '. (is_a($foo, 'Foo') ? 'yes' : 'no') .\n;
echo '$foo instanceof Foo? '. ($foo instanceof Foo ? 'yes' : 'no') .\n;
?
Expected result:
$foo is_a Foo? yes
$foo instanceof Foo? yes
and
$foo is_a Foo? no
$foo instanceof Foo? no
Actual result:
--
$foo is_a Foo? yes
$foo instanceof Foo? yes
and
$foo is_a Foo? no
Fatal error: Class 'Foo' not found in
/home/sean/phpdoc/scripts/tmp/is_a.php on line 8
--
Edit bug report at http://bugs.php.net/?id=29736edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29736r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29736r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29736r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29736r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29736r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29736r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29736r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29736r=support
Expected behavior: http://bugs.php.net/fix.php?id=29736r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29736r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29736r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29736r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29736r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29736r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29736r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29736r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29736r=float
#29736 [Bgs]: instanceof requires class to be loaded
ID: 29736
User updated by: hans at velum dot net
Reported By: hans at velum dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.1
New Comment:
Well, no ... the problem that I am describing has nothing to do with
unserialize(). That was just an example that Sean posted that
illustrates how is_a() and instanceof differ. I apologize if that
wasn't clear.
You did reproduce the bug in your first example.
Simple reproduction:
?php
$c = null;
print '$c instanceof PEAR_Error ? ' . ($c instanceof PEAR_Error);
?
Will result in E_FATAL (no such class). That's the problem. is_a()
has no such limitations, but is now deprecated. This change
suggestion/request is asking for a way to check whether a variable is
an instance of a particular class/superclass/interface *without loading
that class/interface*.
Hope that makes it clearer.
-Hans
Previous Comments:
[2004-08-19 01:28:46] [EMAIL PROTECTED]
Can't reproduce:
[EMAIL PROTECTED] /usr/src/PHP_5_0 $ php -r 'function __autoload($name) {
var_dump($name); } $x = NULL; var_dump($x instanceof test);'
make: `sapi/cli/php' is up to date.
string(4) test
Fatal error: Class 'test' not found in Command line code on line 1
[EMAIL PROTECTED] /usr/src/PHP_5_0 $ php -r 'function __autoload($name) {
var_dump($name); eval(class $name {});} $x = NULL; var_dump($x
instanceof test);'
make: `sapi/cli/php' is up to date.
string(4) test
bool(false)
So the problem lies in unserialize() - other bug
[2004-08-18 16:31:23] hans at velum dot net
Description:
[pasted from messages on internals@ list]
I like the new $obj instanceof ClassName way of checking class /
interface types, but this method does have one major drawback
compared to the old is_a() approach:
The class must be loaded in order to perform an instanceof check!
There are many situations where you do not want to have to load every
class to see whether a returned object is a class of that type. In
particular for driver classes, the current model requires loading
*every* possible driver in order to check to see which type of class
was returned.
is_a() works great, but has been deprecated and is now generating
E_STRICT errors.
Reproduce code:
---
[conributed by Sean Coates on internals@ list]
?php
class Foo {}
$foo = unserialize('O:3:Foo:0:{}');
echo '$foo is_a Foo? '. (is_a($foo, 'Foo') ? 'yes' : 'no') .\n;
echo '$foo instanceof Foo? '. ($foo instanceof Foo ? 'yes' : 'no')
.\n;
?
and
?php
//class Foo {}
$foo = unserialize('O:3:Foo:0:{}');
echo '$foo is_a Foo? '. (is_a($foo, 'Foo') ? 'yes' : 'no') .\n;
echo '$foo instanceof Foo? '. ($foo instanceof Foo ? 'yes' : 'no')
.\n;
?
Expected result:
$foo is_a Foo? yes
$foo instanceof Foo? yes
and
$foo is_a Foo? no
$foo instanceof Foo? no
Actual result:
--
$foo is_a Foo? yes
$foo instanceof Foo? yes
and
$foo is_a Foo? no
Fatal error: Class 'Foo' not found in
/home/sean/phpdoc/scripts/tmp/is_a.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=29736edit=1
#28219 [NEW]: == object comparison produces E_NOTICE
From: hans at velum dot net
Operating system: Linux
PHP version: 5.0.0RC2
PHP Bug Type: Zend Engine 2 problem
Bug description: == object comparison produces E_NOTICE
Description:
I get
Notice: Object of class File could not be converted to integer
when trying to compare object contents using '==' comparison operator.
Comparing the actual reference using === works, but obviously means
something different.
Reproduce code:
---
class File {
public $var;
function __construct($val) {
$this-var = $val;
}
}
$t1 = new File(test);
$t2 = new File(test);
print_r($t1);
print_r($t2);
print \$t1 == \$t2 ?;
if ($t1 == $t2) {
print YES\n;
} else {
print NO\n;
}
Expected result:
File Object
(
[var] = test
)
File Object
(
[var] = test
)
$t1 == $t2 ? YES
Actual result:
--
File Object
(
[var] = test
)
File Object
(
[var] = test
)
$t1 == $t2 ?
Notice: Object of class File could not be converted to integer in
/var/www/apps/ddi/test.php on line 18
Notice: Object of class File could not be converted to integer in
/var/www/apps/ddi/test.php on line 18
YES
--
Edit bug report at http://bugs.php.net/?id=28219edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28219r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28219r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28219r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28219r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28219r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28219r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28219r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28219r=support
Expected behavior: http://bugs.php.net/fix.php?id=28219r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28219r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28219r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28219r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28219r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28219r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28219r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28219r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28219r=float
#28165 [Com]: Missing implicit object to integer conversion
ID: 28165
Comment by: hans at velum dot net
Reported By: daniel at rozsnyo dot com
Status: Suspended
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.*
New Comment:
Using '===' instead of '==' will work, but is semantically different,
right?
$a === $b : are object references the same? i.e. are $a and $b the same
instance.
$a == $b : do the contents match? i.e. do all the variables in object
$a have the same values as the vars in object $b.
If '==' is going to be changed to mean something else, then I think
PHP5 needs an __equals() method so that object contents comparison can
be accomplished.
Previous Comments:
[2004-04-26 21:11:55] rozsnyo at kn dot vutbr dot cz
The notices are also generated on comparison operator (==)
This code:
?php
class A {
public $p;
function __construct($ip) { $this-p = $ip; }
}
$x = new A(1);
$y = $z = new A(2);
echo '$x,$y is ' , ( ($x == $y) ? 'equal': 'not
equal[right]' ), 'br';
echo '$x,$y is ' , ( ($x === $y) ? 'identical': 'not
identical[right]' ), 'br';
echo '$z,$y is ' , ( ($z == $y) ? 'equal[right]' : 'not equal'
), 'br';
echo '$z,$y is ' , ( ($z === $y) ? 'identical[right]' : 'not
identical'), 'br';
?
Produces:
$x,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 11
not equal[right]
$x,$y is not identical[right]
$z,$y is
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 13
equal[right]
$z,$y is identical[right]
At least, please remove the notification and fix the in_array and also
the array_search function (seems that both share the same algorithm -
always two notices as two objects are compared) - the right solution
would be to use the === operator in these functions when the needle is
an object.
This bug is still about:
http://www.php.net/ChangeLog-5.php
Changed array_search() to accept also objects as a needle. (Moriyoshi)
[2004-04-26 20:39:34] [EMAIL PROTECTED]
There are no plans for this. Maybe in PHP 6.
[2004-04-26 19:10:48] daniel at rozsnyo dot com
Description:
While the docs says that i can use use objects as needle, i actually
can not - it might be missing some implicit conversion to integer from
objects.
(I use the published RC2 version (for win32), not the CVS version, the
RC2 option is not available in the listbox for posting a bug-report)
Another problem is the notice (in RC1 there was no notice, here is a
notice... so I am posting as bug... by the way, it would be nice to
have functions like __toInteger() [in_array], __toArray() [for]
besides the known __toString [echo,print]
Daniel
Reproduce code:
---
?php
class A { }
$a = Array( new A, new A, new A );
echo $x = new A; // should be object # 4
echo (in_array($x,$a)) ? 'There' : 'NOT there';
?
Expected result:
I am expecting this result:
---
Object id #4
NOT there
Actual result:
--
Look to notices:
---
Object id #4
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 9
Notice: Object of class A could not be converted to integer in
C:\www\default\test\index.php on line 9
There
--
Edit this bug report at http://bugs.php.net/?id=28165edit=1
#26695 [NEW]: Reflection API does not recognize mixed-case class hints
From: hans at velum dot net
Operating system: Linux, Windows
PHP version: 5CVS-2003-12-22 (dev)
PHP Bug Type: Class/Object related
Bug description: Reflection API does not recognize mixed-case class hints
Description:
This is a problem in PHP 5.0.0b3 (distro), which wasn't an option in the
bug report select list.
Basically, upon upgrading to PHP5.0.0b3 our application generated runtime
Reflection_Exceptions claiming to be unable to find the class specified by
a class hint.
E.g. when calling
$params = $method-getParameters();
$hint = $params[0]-getClass();
Changing the class hint to lowercase fixes this problem.
Reproduce code:
---
class Foo {
}
class Bar {
function demo(Foo $f) {
// nothing
}
}
$class = new Reflection_Class('Bar');
$methods = $class-getMethods();
$params = $methods[0]-getParameters();
$hint = $params[0]-getClass();
// reflection_exception was thrown
print Class expected is: . $hint . \n;
Expected result:
Class expected is: Foo
Actual result:
--
bFatal error/b: Uncaught exception 'reflection_exception' with
message 'Class Foo does not exist' in ...
--
Edit bug report at http://bugs.php.net/?id=26695edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26695r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26695r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26695r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26695r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26695r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26695r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26695r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26695r=support
Expected behavior: http://bugs.php.net/fix.php?id=26695r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26695r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26695r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26695r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26695r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26695r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26695r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26695r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26695r=float
#24939 [NEW]: Variable method names have become less flexible
From: hans at velum dot net
Operating system: Linux (Debian)
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: Zend Engine 2 problem
Bug description: Variable method names have become less flexible
Description:
Smarty uses a rather complex variable method name replacement system. In
the compiled Smarty templates there is code like this:
$this-_plugins['function']['assign'][0](/* params */)
Which works fine in PHP4, but PHP5 issues a fatal error:
Fatal error: Method name must be a string
Is this a PHP5 bug or an abuse of PHP syntax (and therefore a Smarty bug)?
Reproduce code:
---
A Smarty compiled template:
?php $this-_load_plugins(array(
array('function', 'assign', 'sql/db-init/Control.tpl', 1, false),));
??php echo $this-_plugins['function']['assign'][0](array('var' =
'fname','value' =
sql/db-init/.$this-_tpl_vars['targetDatabase']./createdb.tpl), $this)
; ?
?php $_smarty_tpl_vars = $this-_tpl_vars;
$this-_smarty_include($this-_tpl_vars['fname'], array());
$this-_tpl_vars = $_smarty_tpl_vars;
unset($_smarty_tpl_vars);
?
~
Expected result:
No error.
Actual result:
--
Fatal error: Method name must be a string in
templates_c/%%-16/%%-1662958972/Control.tpl.php
--
Edit bug report at http://bugs.php.net/?id=24939edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24939r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24939r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24939r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24939r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24939r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24939r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24939r=support
Expected behavior: http://bugs.php.net/fix.php?id=24939r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24939r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24939r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24939r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24939r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24939r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24939r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24939r=gnused
#24595 [NEW]: Cannot bind output variables.
From: hans at velum dot net
Operating system: Windows XP
PHP version: 5.0.0b1 (beta1)
PHP Bug Type: MSSQL related
Bug description: Cannot bind output variables.
Description:
When using mssql_bind() to bind an output variable, the variable is passed
into the stored procedure but the modified value is not returned. (The
variable is being passed by reference to mssql_bind()).
Reproduce code:
---
I used the following user-contributed example from mssql_execute manual
page.
if we have this procedure:
CREATE PROCEDURE [procedure]
(
@sval varchar(50) OUTPUT,
@intval int OUTPUT,
@floatval decimal(6,4) OUTPUT
) AS
if @intval is null
select '@intval is null' as answer
else
select '@intval is NOT null' as answer
set @sval='Hello ' + @sval
set @[EMAIL PROTECTED]
set @[EMAIL PROTECTED]
return 10
We can use this PHP code:
?php
$conn=mssql_connect(myhost,user,pwd);
if ($conn) {
mssql_select_db(mydb,$conn);
$stmt=mssql_init(procedure,$conn);
mssql_bind($stmt,RETVAL,$val,SQLINT4);
$ival=11;
$fval=2.1416;
$sval=Frank;
mssql_bind($stmt,@sval,$sval,SQLVARCHAR,TRUE);
mssql_bind($stmt,@intval,$ival,SQLINT4,TRUE);
mssql_bind($stmt,@floatval,$fval,SQLFLT8,TRUE);
$result=mssql_execute($stmt);
$arr=mssql_fetch_row($result);
print (Answer: . $arr[0] .
);
print (RETVAL = $val ; intval = $ival ; floatval = $fval ; string =
$sval);
mssql_close($conn);
}
else print(ooops!);
Expected result:
Answer: @intval is NOT nullRETVAL = 10 ; intval = 12 ; floatval = 3.1416 ;
string = Hello Frank
Actual result:
--
Answer: @intval is NOT nullRETVAL = 0 ; intval = 11 ; floatval = 2.1416 ;
string = Frank
--
Edit bug report at http://bugs.php.net/?id=24595edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24595r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24595r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24595r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24595r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24595r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24595r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24595r=support
Expected behavior: http://bugs.php.net/fix.php?id=24595r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24595r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24595r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24595r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24595r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24595r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24595r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24595r=gnused
#24595 [Fbk-Opn]: Cannot bind output variables.
ID: 24595
User updated by: hans at velum dot net
Reported By: hans at velum dot net
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Windows XP
PHP Version: 5.0.0b1 (beta1)
New Comment:
Yes, I verified that this is also happening with 4.3.2. I thought,
based on a comment in the manual, that this was not an issue in the
4.3.2 release.
I also verified that the bound values are making it *into* the stored
procedure w/o incident. (E.g. I can add them to the returned result
row to see that the stored procedure is aware of the values.)
Previous Comments:
[2003-07-10 12:52:15] [EMAIL PROTECTED]
Does this happen with PHP 4.3.2 ?
[2003-07-10 12:35:09] hans at velum dot net
Description:
When using mssql_bind() to bind an output variable, the variable is
passed into the stored procedure but the modified value is not
returned. (The variable is being passed by reference to mssql_bind()).
Reproduce code:
---
I used the following user-contributed example from mssql_execute manual
page.
if we have this procedure:
CREATE PROCEDURE [procedure]
(
@sval varchar(50) OUTPUT,
@intval int OUTPUT,
@floatval decimal(6,4) OUTPUT
) AS
if @intval is null
select '@intval is null' as answer
else
select '@intval is NOT null' as answer
set @sval='Hello ' + @sval
set @[EMAIL PROTECTED]
set @[EMAIL PROTECTED]
return 10
We can use this PHP code:
?php
$conn=mssql_connect(myhost,user,pwd);
if ($conn) {
mssql_select_db(mydb,$conn);
$stmt=mssql_init(procedure,$conn);
mssql_bind($stmt,RETVAL,$val,SQLINT4);
$ival=11;
$fval=2.1416;
$sval=Frank;
mssql_bind($stmt,@sval,$sval,SQLVARCHAR,TRUE);
mssql_bind($stmt,@intval,$ival,SQLINT4,TRUE);
mssql_bind($stmt,@floatval,$fval,SQLFLT8,TRUE);
$result=mssql_execute($stmt);
$arr=mssql_fetch_row($result);
print (Answer: . $arr[0] .
);
print (RETVAL = $val ; intval = $ival ; floatval = $fval ; string =
$sval);
mssql_close($conn);
}
else print(ooops!);
Expected result:
Answer: @intval is NOT nullRETVAL = 10 ; intval = 12 ; floatval =
3.1416 ; string = Hello Frank
Actual result:
--
Answer: @intval is NOT nullRETVAL = 0 ; intval = 11 ; floatval = 2.1416
; string = Frank
--
Edit this bug report at http://bugs.php.net/?id=24595edit=1
