[PHP-BUG] Bug #65530 [NEW]: Anonymous functions not callable directly when part of a static class
From: matt dot minix at gmail dot com
Operating system: Linux
PHP version: 5.4.18
Package: Variables related
Bug Type: Bug
Bug description:Anonymous functions not callable directly when part of a static
class
Description:
An anonymous function doesn't seem like it can be called directly when in a
static
class.
Test script:
---
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
a::$b('Test');
I am however able to do
class a {
public static $b;
}
a::$b = static function($c) { echo $c; };
$Temp = a::$b;
$Temp('Test');
Expected result:
Test
Actual result:
--
Fatal error: Function name must be a string
--
Edit bug report at https://bugs.php.net/bug.php?id=65530edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65530r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65530r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65530r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65530r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65530r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65530r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65530r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65530r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65530r=support
Expected behavior: https://bugs.php.net/fix.php?id=65530r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65530r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65530r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65530r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65530r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65530r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65530r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65530r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65530r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65530r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65530r=mysqlcfg
Bug #54547 [Com]: wrong equality of string numbers
Edit report at https://bugs.php.net/bug.php?id=54547edit=1 ID: 54547 Comment by: the dot matt dot kantor at gmail dot com Reported by:peter dot ritt at gmx dot net Summary:wrong equality of string numbers Status: Verified Type: Bug Package:Unknown/Other Function Operating System: linux PHP Version:5.3.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: @hholzgra: Your only-coerce-on-failure proposal would not solve this issue. Assuming that by fail you mean the comparison evaluates to false, the strings would end up being coerced anyway (since they are indeed different), they'd become identical floats, and things would be the same as they are now. If I misunderstood what you meant by fail, then we'd lose 1 == 1.0, which I don't think is something that can (or should) happen. Previous Comments: [2012-04-12 22:45:28] erowid at inbox dot lv I want to marry it, lather this thread up, and have my way with it. I want to have little threads everywhere that are as funny as this xD [2012-04-12 22:14:36] chx1975 at gmail dot com Now, while I can understand why PHP chooses 1 == 1 (HTML, sure) I am not too sure how is that relevant when both sides are strings?? I am not quite sure why the strings 1 and 1.0 would need to be ==. Just because 1 == 1 and 1.0 == 1 does not mean 1 == 1.0. It's not transitive! Compare FALSE == 0; 0 == 'x'; 'x' == TRUE -- if it would be transitive then FALSE == TRUE, surely you don't want that. [2012-04-12 21:23:40] vinny_182 at hotmail dot com Equality is equality and neither string or numeric representations of the value are equal. The bug IMO is in the conversion from string to float, the conversion has failed but a valid value is still returned. That's just plain wrong. If you wrote unit tests for string to float conversions and this was the input you would expect it to return a null value or throw an exception. [2012-04-12 21:02:06] c at hotmail dot com In the majority of cases when dealing with HTTP requests and database results, which is what PHP deals with most, the loose comparison makes life easiest on the developer. By 'the developer' I assume you mean people who can't type (string) or (int) ? No other language has this issue because they aren't designed around programmers who do not really understand how to program. Please make the developer's life easier by making comparisons make sense. [2012-04-12 20:38:48] elementation at gmail dot com It's absolutely unreal that this is even a discussion. PHP, the world doesn't take you seriously and with bugs like this you provide further fodder. Principle of Least Surprise â this should be a string comparison. 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=54547 -- Edit this bug report at https://bugs.php.net/bug.php?id=54547edit=1
Req #14285 [Com]: Forcing variable declaration
Edit report at https://bugs.php.net/bug.php?id=14285edit=1
ID: 14285
Comment by: matt at mattandwell dot net
Reported by:pnh102 at psu dot edu
Summary:Forcing variable declaration
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
This would be a great option to add in error_reporting, consider the following
script.
ini_set(error_reporting, E_ALL|E_STRICT);
class test1
{
private $m1 = initial value in t1;
public function setVarsTest()
{
$this-m1 = in t1;
}
public function showValues()
{
echo().$this-m1.(br/);
}
}
class test2 extends test1
{
public function setVarsTest()
{
$this-m1 = in t2;
}
}
$t1 = new test1();
$t1-setVarsTest();
$t1-showValues();
$t2 = new test2();
$t2-setVarsTest();
$t2-showValues();
the output is:
)in t1(
)initial value in t1(
changing $m1 to protected solves the issue, but tracking down issues like this
after a refactoring session could be easier if PHP had this feature.
$t2-setVarsTest(); would generate a notice in the above code.
Previous Comments:
[2008-06-13 11:27:34] gvdefence-ncr at yahoo dot it
This feature is necessary in PHP.
Try this simple example:
error_reporting(E_ALL | E_NOTICE | E_STRICT); //E_STRICT for PHP5
class Test
{
var $mispelled_var;
function Test($test)
{
$this-$mispeled_var = $test;
/*
ERROR: we think to instantiate $this-mispelled_var, but
we forgot an 'l' and we are instantiating a new var.
PHP does not raise any error or warning or notice.
*/
}
};
All other languages would raise an error or at least a warning.
I love PHP and I want it to grow, this is a neccesary feature.
It is necessary to add a sort of gobal option that when activated makes PHP
sensible to these type of errors.
[2004-07-22 09:49:24] jeffrparsons at optushome dot com dot au
I agree this is a very major issue, and it scares people I know away from using
PHP. It would be extremely convenient to have warnings on assignment as well -
instead of just upon reading a non-existent variable - and instead of creating
a variable when a value is first assigned to it, require a separate declaration
using a var keyword or such. Obviously not as standard, but as an option...
[2003-08-13 14:35:52] lsemel at yahoo dot com
This is an important issue. E_ALL doesn't catch everything. It makes PHP
harder to program compared to other languages where you can declare variables
(Perl, Java, etc.)
[2003-07-16 15:36:44] andrew_nefsky at hotmail dot com
This is definitely an important issue. Not being able to declare variables
creates a debugging nightmare!
[2002-11-19 08:06:07] z95kahe at mtek dot chalmers dot se
I realy think this is good idea. I've been looking for some tool to do this
kind of checks and found none.
For small scripts there is no need to have variable declaring but there are for
longer multi file, multi developer projects. By making the checks an option we
can have both modes available.
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=14285
--
Edit this bug report at https://bugs.php.net/bug.php?id=14285edit=1
Bug #56081 [Com]: header files not installed + dependencies
Edit report at https://bugs.php.net/bug.php?id=56081edit=1 ID: 56081 Comment by: matt at kynx dot org Reported by:matt at kynx dot org Summary:header files not installed + dependencies Status: Feedback Type: Bug Package:*General Issues Operating System: RedHat 9 PHP Version:5CVS-2004-05-30 (dev) Block user comment: N Private report: N New Comment: Can't remember having this problem in the last seven-odd years of using PDO ;) Think it's safe to close. Happy hols. Previous Comments: [2011-12-24 06:25:20] ssuffic...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2004-05-30 10:19:59] matt at kynx dot org Description: Seems that the header files (in particular php_pdo_driver.h) were not installed with the package. This caused installation of the drivers to fail. Workaround was to manually copy the header files from the tar archive to: /usr/local/include/php/ext/pdo. Also pdo_mysql-1.0.tgz falsely reports PHP version = 5.0.0 is required and had to be installed with --nodeps. Can't wait to start using this! Reproduce code: --- pear install PDO-0.1.1.tgz pear install --nodeps pdo_mysql-0.1.tgz Expected result: snip Build process completed successfully Installing 'pdo_mysql.so' at ext_dir (/usr/local/lib/php/20040412/pdo_mysql.so) install ok: pdo_mysql 0.1 Actual result: -- snip configure: error: Cannot find php_pdo_driver.h. `/tmp/tmpUfBBnG/pdo_mysql-0.1/configure' failed -- Edit this bug report at https://bugs.php.net/bug.php?id=56081edit=1
Bug #55108 [Com]: Unable to compile with MySQL
Edit report at https://bugs.php.net/bug.php?id=55108edit=1 ID: 55108 Comment by: matt dot fellows at onegeek dot com dot au Reported by:s21122012 at yahoo dot com Summary:Unable to compile with MySQL Status: Open Type: Bug Package:Compile Failure Operating System: Mac OS X 10.6.8 PHP Version:5.4.0alpha1 Block user comment: N Private report: N New Comment: I had the same issue with php 5.3.8 on Lion, but unfortunately I'm unable to use the mysqlnd option due to the fact that the database I'm connecting to is MySQL v3. Assuming a default MySQL installation (5.5.15 using either image or source), I was able to solve the issue with the following command: sudo install_name_tool -id /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient.dylib Hope this helps someone. Cheers, Matt Previous Comments: [2011-08-29 23:10:02] aaronh at bind dot com Same issue here running Lion Server / 10.7.1 and php-5.3.8 with the mysql binary. mysql-5.5.15-osx10.6-x86_64.tar.gz Darwin 6c1.sjc.6connect.com 11.0.1 Darwin Kernel Version 11.0.1: Thu Jul 28 02:01:39 PDT 2011; root:xnu-1699.23.4~1/RELEASE_X86_64 x86_64 Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure - -disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 -- mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- - -program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib -- build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42- 2335.15~25/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple- darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx- include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) [2011-07-01 18:12:31] s21122012 at yahoo dot com Thank you for your reply! I used the binary package when I posted the issue, but I had tried with a version compiled by myself before and the result was the same. Here is the file you requested (it was compiled using only the --prefix, --with-apxs2, --with- mysql and --with-mysqli flags): http://dl.dropbox.com/u/4460937/php_config.h I have been able to compile it with MySQL support using the native driver (mysqlnd), as suggested by you. I would also like to mention that I had similar errors with PHP 5.3.6 in the past. I am not sure if the conflict was between the same macros, though. [2011-07-01 16:22:28] johan...@php.net These might be caused by conflicts in the usage of either HAVE_DNS_SEARCH or HAVE_RES_NSEARCH between MySQL libs and PHP. Did you use MySQL binary packages or did you compile MySQL yourself? I have no Mac at hand, could you please send me the file main/php_config.h from the failing build? - Thanks. (As remark: You could build PHP using mysqlnd instead of libmysql by using --with-mysql=mysqlnd --with-mysqli=mysqlnd - but your issue should be fixed anyways.) [2011-07-01 15:04:34] s21122012 at yahoo dot com Description: I'm trying to compile PHP 5.4 alpha 1 with MySQL support using the configuration commands in Version 1. It produces the error below. If I use Version 2 (that is, no MySQL), it works. MySQL is 5.5.13 x86_64. Test script: --- Version 1 -- ./configure --prefix=/alt --with-apxs2=/alt/apache/bin/apxs --with-openssl=/alt --with-zlib=/alt --with-curl=/alt --with-gmp=/alt --with-libxml-dir=/alt --enable-ftp --disable-cgi --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config Version 2 -- ./configure --prefix=/alt --with-apxs2=/alt/apache/bin/apxs --with-openssl=/alt --with-zlib=/alt --with-curl=/alt --with-gmp=/alt --with-libxml-dir=/alt --enable-ftp --disable-cgi Expected result: Build complete Actual result: -- Undefined symbols for architecture x86_64: _res_9_init, referenced from: _zif_dns_get_mx in dns.o _zif_dns_get_record in dns.o _zif_dns_check_record in dns.o _res_9_search, referenced from: _zif_dns_get_mx in dns.o _zif_dns_get_record in dns.o _zif_dns_check_record in dns.o _res_9_dn_skipname, referenced from: _zif_dns_get_mx in dns.o _zif_dns_get_record in dns.o _res_9_dn_expand, referenced from: _zif_dns_get_mx in dns.o _php_parserr in dns.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1
[PHP-BUG] Req #54865 [NEW]: Child process inherits parent priority
From: Operating system: Windows Server 2008 R2 PHP version: 5.3.6 Package: Program Execution Bug Type: Feature/Change Request Bug description:Child process inherits parent priority Description: I'm running PHP in above-normal priority and would like to have child processes of it, spawned using proc_open, to inherit that priority level. In Windows I believe this should just be a matter of running: SetPriorityClass( GetCurrentProcess(), desired_priority ); I'm not sure if this is a bug report or a feature request though, I guess it depends on how you view it. Test script: --- $path = c:\\windows\\system32\\notepad.exe; $descriptorspec = array(); $cwd = c:\\windows\\temp; $env = NULL; $other_options = array( 'bypass_shell' = FALSE, ); $resource = proc_open( $path, $descriptorspec, $pipes, $cwd, $env, $other_options ); Expected result: I expect the notepad.exe to have the abovenormal priority level, which is what the parent php script was running at. Actual result: -- notepad.exe runs at the normal priority level. -- Edit bug report at http://bugs.php.net/bug.php?id=54865edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54865r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54865r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54865r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54865r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54865r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54865r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54865r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54865r=needscript Try newer version: http://bugs.php.net/fix.php?id=54865r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54865r=support Expected behavior: http://bugs.php.net/fix.php?id=54865r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54865r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54865r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54865r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54865r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54865r=dst IIS Stability: http://bugs.php.net/fix.php?id=54865r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54865r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54865r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54865r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54865r=mysqlcfg
Req #49806 [Com]: proc_nice() for Windows
Edit report at http://bugs.php.net/bug.php?id=49806edit=1 ID: 49806 Comment by: matt at wootkit dot com Reported by:ka...@php.net Summary:proc_nice() for Windows Status: Assigned Type: Feature/Change Request Package:Program Execution Operating System: Windows PHP Version:6SVN-2009-10-07 (SVN) Assigned To:pajoye Block user comment: N Private report: N New Comment: I'd also like to see this function added. This would be very useful, especially in reference to request #54865 (http://bugs.php.net/bug.php?id=54865) Previous Comments: [2009-10-07 20:20:54] ka...@php.net Description: As discussed with Pierre and sent to the internals-win ML, then here is a patch for enabling proc_nice() under Windows. This patch is abit modified from the version sent to the ML and is added into TSRM like popen. Patch is made for trunk: http://pastie.org/645963 -- Edit this bug report at http://bugs.php.net/bug.php?id=49806edit=1
Req #34570 [Com]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570edit=1
ID: 34570
Comment by: matt at mralston dot co dot uk
Reported by:steve-php-dev at spwiz dot com
Summary:Implement some sort of setproctitle() in cli version
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux 2.4 kernel
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
Fantastic!
In the dictionary, there's an entry for short and sweet, and next to
it is your post!
Thank you very much. And thank you PECL. And thank you Wikipedia!
I've never given PECL much attention before; I now see the error of my
ways.
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME
COMMAND
daemon7269 0.0 0.0 124696 3500 ?Ss 11:59 0:00
[CAIMan]
I'm a happy bunny! Thank you.
Previous Comments:
[2011-01-23 08:03:31] dtajchre...@php.net
http://pecl.php.net/package/proctitle
[2011-01-23 01:48:45] matt at mralston dot co dot uk
I can't stress how much I'd like to see this feature implemented.
I'm not a C programmer and I haven't got a clue how PHP is structured
behind the
scenes, but I can't
imagine that this feature would be difficult to implement.
I've been through a quite a journey with this conundrum today. I started
out
coding a new daemon
this morning. Began to wish I could change the /usr/bin/php
./caiman.php start
entry in the ps
auxw listing this afternoon. I then spent some time researching how to
do it
(which was fustrating
because I didn't even know how to phrase the question for Google when I
started). I eventually found
some C++ forums talking about modifying argv[0] and was excited and then
disappointed when I found it
didn't work in PHP. I drafted out a long e-mail I intended to send to
the PHP
developers, then figured
I'd better properly RTFM and check out the bug tracker first. That's
when I came
across this feature request
(and an older one from 2002). Unfortunately both appear to have
stalled.
So here I am, adding my voice to this request. I can grovel if you
like!
Please, please, please would somebody have a go at adding this feature
when
they've got some spare
time? Even if the feature is ultimately rejected for inclusion into the
trunk, a
little patch that I
could apply to my own servers would be appreciated so much.
In the meantime, I'm just about to start poking around the PHP sources
on my
development box and see
if I can implement something myself. As I said, I'm not a C programmer
so I
expect to struggle, but
it's worth a shot. I'm thinking of something like:
void pcntl_setproctitle(char *new_title)
{
sprintf(argv[0], new_title);
}
Thanks for listening to me ramble.
- Matt
[2005-09-20 23:39:12] steve-php-dev at spwiz dot com
Description:
I'm using the pcntl module in the CLI SAPI to fork off several
processes. I'd like the processes to be able to identify themselves in
ps. In Linux, you can do this by editing argv[0]. On BSD, you use the
setproctitle() function. Other higher level languages support this
feature. A simple perl script to do this on Linux would be:
$0 = bogus;
sleep 10;
I tried modifying $argv[0], but that only modified the PHP scripts copy
of argv, not the real argv. It'd be nice if there was a way to modify
the process title directly. Ideally, it would be cross-platform (for
Unix variants, at least).
This was originally requested in 2002
(http://bugs.php.net/bug.php?id=18400), but was rejected. When using
the pcntl functions in the CLI version, it really would be a useful
feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=34570edit=1
Req #34570 [Com]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570edit=1
ID: 34570
Comment by: matt at mralston dot co dot uk
Reported by:steve-php-dev at spwiz dot com
Summary:Implement some sort of setproctitle() in cli version
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux 2.4 kernel
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
I can't stress how much I'd like to see this feature implemented.
I'm not a C programmer and I haven't got a clue how PHP is structured
behind the
scenes, but I can't
imagine that this feature would be difficult to implement.
I've been through a quite a journey with this conundrum today. I started
out
coding a new daemon
this morning. Began to wish I could change the /usr/bin/php
./caiman.php start
entry in the ps
auxw listing this afternoon. I then spent some time researching how to
do it
(which was fustrating
because I didn't even know how to phrase the question for Google when I
started). I eventually found
some C++ forums talking about modifying argv[0] and was excited and then
disappointed when I found it
didn't work in PHP. I drafted out a long e-mail I intended to send to
the PHP
developers, then figured
I'd better properly RTFM and check out the bug tracker first. That's
when I came
across this feature request
(and an older one from 2002). Unfortunately both appear to have
stalled.
So here I am, adding my voice to this request. I can grovel if you
like!
Please, please, please would somebody have a go at adding this feature
when
they've got some spare
time? Even if the feature is ultimately rejected for inclusion into the
trunk, a
little patch that I
could apply to my own servers would be appreciated so much.
In the meantime, I'm just about to start poking around the PHP sources
on my
development box and see
if I can implement something myself. As I said, I'm not a C programmer
so I
expect to struggle, but
it's worth a shot. I'm thinking of something like:
void pcntl_setproctitle(char *new_title)
{
sprintf(argv[0], new_title);
}
Thanks for listening to me ramble.
- Matt
Previous Comments:
[2005-09-20 23:39:12] steve-php-dev at spwiz dot com
Description:
I'm using the pcntl module in the CLI SAPI to fork off several
processes. I'd like the processes to be able to identify themselves in
ps. In Linux, you can do this by editing argv[0]. On BSD, you use the
setproctitle() function. Other higher level languages support this
feature. A simple perl script to do this on Linux would be:
$0 = bogus;
sleep 10;
I tried modifying $argv[0], but that only modified the PHP scripts copy
of argv, not the real argv. It'd be nice if there was a way to modify
the process title directly. Ideally, it would be cross-platform (for
Unix variants, at least).
This was originally requested in 2002
(http://bugs.php.net/bug.php?id=18400), but was rejected. When using
the pcntl functions in the CLI version, it really would be a useful
feature.
--
Edit this bug report at http://bugs.php.net/bug.php?id=34570edit=1
Req #49542 [Com]: __callStatic() only invoked if instance method does not exist
Edit report at http://bugs.php.net/bug.php?id=49542edit=1
ID: 49542
Comment by: matt dot lubner at gmail dot com
Reported by:mjs at beebo dot org
Summary:__callStatic() only invoked if instance method does
not exist
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Ubuntu
PHP Version:5.3.0
Block user comment: N
New Comment:
With PHP 5.3.2, if the instance method bar() is *not* public, and
__callStatic()
*is*, __callStatic() will be invoked, because bar() won't be in scope.
Unfortunately, this seems like a horribly hacked work-around. Ideally,
public
instance methods should not be in scope from a static context, so
__callStatic()
will be called instead.
Previous Comments:
[2009-09-13 14:34:38] mjs at beebo dot org
Description:
A static call to Foo::bar() does not invoke __callStatic() if an
instance method bar() exists.
One reason you might want this is to convert static calls to Foo::bar()
to the equivalent operation on a singleton:
public static function __callStatic($name, $args) {
$obj = self::getInstance();
return call_user_func_array(array($obj, $name), $args);
}
In the sample code below, __callStatic() is not invoked even though the
caller has deliberately initiated a static call.
Reproduce code:
---
?php
class Foo {
public static function __callStatic($name, $args) {
echo In __callStatic()\n;
}
public function bar() {
echo In bar()\n;
}
}
echo Foo::bar();
Expected result:
In _callStatic()
Actual result:
--
PHP Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
In bar()
--
Edit this bug report at http://bugs.php.net/bug.php?id=49542edit=1
Req #49542 [Com]: __callStatic() only invoked if instance method does not exist
Edit report at http://bugs.php.net/bug.php?id=49542edit=1
ID: 49542
Comment by: matt dot lubner at gmail dot com
Reported by:mjs at beebo dot org
Summary:__callStatic() only invoked if instance method does
not exist
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Ubuntu
PHP Version:5.3.0
Block user comment: N
New Comment:
I should have also mentioned that calling an instance method in a static
context
does not generate an error, unless the called method has any references
to $this
(which of course is not in scope), in which case a fatal error occurs.
This can
be a little tricky to track down, and so would be preferable if instance
methods
were simply not in scope for static contexts.
Previous Comments:
[2010-10-15 03:40:41] matt dot lubner at gmail dot com
With PHP 5.3.2, if the instance method bar() is *not* public, and
__callStatic()
*is*, __callStatic() will be invoked, because bar() won't be in scope.
Unfortunately, this seems like a horribly hacked work-around. Ideally,
public
instance methods should not be in scope from a static context, so
__callStatic()
will be called instead.
[2009-09-13 14:34:38] mjs at beebo dot org
Description:
A static call to Foo::bar() does not invoke __callStatic() if an
instance method bar() exists.
One reason you might want this is to convert static calls to Foo::bar()
to the equivalent operation on a singleton:
public static function __callStatic($name, $args) {
$obj = self::getInstance();
return call_user_func_array(array($obj, $name), $args);
}
In the sample code below, __callStatic() is not invoked even though the
caller has deliberately initiated a static call.
Reproduce code:
---
?php
class Foo {
public static function __callStatic($name, $args) {
echo In __callStatic()\n;
}
public function bar() {
echo In bar()\n;
}
}
echo Foo::bar();
Expected result:
In _callStatic()
Actual result:
--
PHP Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
Strict Standards: Non-static method Foo::bar() should not be called
statically in /mnt/hgfs/workspace/scratch/wart1.php on line 15
In bar()
--
Edit this bug report at http://bugs.php.net/bug.php?id=49542edit=1
Bug #52028 [Com]: php.ini not loaded
Edit report at http://bugs.php.net/bug.php?id=52028edit=1 ID: 52028 Comment by: matt at luggagepros dot com Reported by:samuel dot deal at allomusic dot com Summary:php.ini not loaded Status: Open Type: Bug Package:*General Issues Operating System: Linux Ubuntu 10.04 PHP Version:5.2.13 Block user comment: N New Comment: Confirmed. PHP 5.2.14 on CentOS 5.4 Had used buildconf to add imagick PECL static extension. Solution was to make clean, remove configure, buildconf (as root), configure (with the same arguments), then make. Previous Comments: [2010-06-09 11:51:27] samuel dot deal at allomusic dot com Description: My php.ini is not loaded when I'm using cgi module with Apache2 extract of phpinfo: Configuration File (php.ini) Path /etc/php5.2/cgi Loaded Configuration File (None) I have this error compiling php 5.2.13. Compiling the 5.2.10 version with the same compilation options and same php.ini file and location does'nt produce this error. I think I have done somethings wrong, it's such a big issue. But I can't see what... perhaps a conflict with 5.3.2 version. But this conflict doesn't exists for 5.2.10 version System Config: -- Ubuntu 10.04 x86 desktop Apache 2.2.14 I have php 5.3.2 installed as cgi form ubuntu repository Compilation Options: ./configure \ --sysconfdir=/etc \ --disable-debug \ --with-regex=php \ --disable-rpath \ --disable-static \ --with-pic \ --with-layout=GNU \ --with-pear=/usr/local/share/php5.2 \ --enable-calendar \ --enable-sysvsem \ --enable-sysvshm \ --enable-sysvmsg \ --enable-bcmath \ --with-bz2 \ --enable-ctype \ --with-db4 \ --without-gdbm \ --with-iconv \ --enable-exif \ --enable-ftp \ --with-gettext \ --enable-mbstring \ --with-pcre-regex=/usr \ --enable-shmop \ --enable-sockets \ --enable-wddx \ --with-libxml-dir=/usr \ --with-zlib \ --with-kerberos=/usr \ --with-openssl=/usr \ --enable-soap \ --enable-zip \ --with-mhash=yes \ --with-exec-dir=/etc/php5.2/libexec \ --with-config-file-path=/etc/php5.2/cgi \ --with-config-file-scan-dir=/etc/php5.2/cgi/conf.d \ --program-suffix=5.2 Make test results: = TEST RESULT SUMMARY - Exts skipped: 55 Exts tested : 24 - Number of tests : 8889 6569 Tests skipped : 2320 ( 26.1%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed: 11 ( 0.1%) ( 0.2%) Expected fail :4 ( 0.0%) ( 0.1%) Tests passed: 6554 ( 73.7%) ( 99.8%) - Time taken : 336 seconds = = FAILED TEST SUMMARY - Bug #45877 (Array key '2147483647' left as string) [Zend/tests/bug45877.phpt] Test DateTime::modify() function : usage variation - Passing unexpected values to first argument $modify. [ext/date/tests/DateTime_modify_variation1.phpt] Test date_modify() function : usage variation - Passing unexpected values to second argument $format. [ext/date/tests/date_modify_variation2.phpt] Test date_sunrise() function : usage variation - Passing unexpected values to fifth argument zenith [ext/date/tests/date_sunrise_variation5.phpt] Integer overflow [ext/filter/tests/046.phpt] Test posix_kill(), posix_get_last_error and posix_strerror() functions : basic functionality [ext/posix/tests/posix_kill_basic.phpt] Test array_pad() function : usage variations - unexpected values for 'pad_size' argument(Bug#43482) [ext/standard/tests/array/array_pad_variation2.phpt] proc_open [ext/standard/tests/general_functions/proc_open02.phpt] Test var_export() function with valid float values [ext/standard/tests/general_functions/var_export_basic3.phpt] time_sleep_until() function - basic test for time_sleep_until() [ext/standard/tests/misc/time_sleep_until_basic.phpt] Bug #32001 (xml_parse*() goes into infinite loop when autodetection in effect), using UTF-* [ext/xml/tests/bug32001.phpt] = = EXPECTED FAILED TEST SUMMARY - output buffering - fatalism [tests/output/ob_011.phpt] ob_start(): Ensure unerasable buffer cannot be flushed by ob_flush() [tests/output/ob_start_basic_unerasable_005.phpt] Bug #42718 (unsafe_raw
#50207 [NEW]: segmentation fault when concatenating very large strings on 64bit linux
From: matt at bitwarehouse dot com
Operating system: CentOS 5 x64
PHP version: 5.2.11
PHP Bug Type: Scripting Engine problem
Bug description: segmentation fault when concatenating very large strings on
64bit linux
Description:
When concatenating values to a string of length = 2^31, a segmentation
fault will occur in memcpy on 64 bit Linux. This appears to be caused
by the signed int length of the string (overflowed to negative) being
cast to unsigned long long when added to an 8 byte pointer in
Zend/zend_operators.c:concat_function.
This also occurs in PHP 5.3.0.
In PHP 5.1.6, a fatal erealloc error would be issued when the variable
hit (2^31)+1 (INT_MAX) to prevent overflow. This however is gone in PHP
5.2.
It is also unclear if PHP and its string functions are supposed to
support strings larger than 2GB.
Reproduce code:
---
?php
// run me with: php -d memory_limit=-1
$s = str_repeat('A', pow(2,31));
$s .= 'B'; // fails with segfault
printf(strlen: %u last-char: %c, strlen($s), $s[pow(2,31)-1]);
?
Expected result:
Either:
strlen: 2147483649 last-char: B
-or-
FATAL: erealloc(): Unable to allocate XXX bytes
with the understanding that strings cannot contain more than 2^31 bytes
Actual result:
--
PHP 5.2.11 and 5.3.0 were compiled with no configure arguments, no
patches, no extra extensions on 64bit CentOS 5.
E.g. ./configure make
#presume a.php contains reproduce code
% ./sapi/cli/php -d memory_limit=-1 a.php
Segmentation fault
Backtrace of segfault:
Program received signal SIGSEGV, Segmentation fault.
0x003897a7bdc1 in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003897a7bdc1 in memcpy () from /lib64/libc.so.6
#1 0x0060a520 in concat_function (result=value optimized
out, op1=0x1c32ba60, op2=0x1c32c850) at /home/matt/tmp/php-
5.2.11/Zend/zend_operators.c:1208
#2 0x00676623 in zend_binary_assign_op_helper_SPEC_CV_CONST
(binary_op=0x60a3c0 concat_function, execute_data=0x7fff4e789070) at
/home/matt/tmp/php-5.2.11/Zend/zend_vm_execute.h:21034
#3 0x0062fd73 in execute (op_array=0x1c32c278) at
/home/matt/tmp/php-5.2.11/Zend/zend_vm_execute.h:92
#4 0x006117a3 in zend_execute_scripts (type=8,
retval=0x2b47b33ea030, file_count=3) at /home/matt/tmp/php-
5.2.11/Zend/zend.c:1134
#5 0x005d164b in php_execute_script
(primary_file=0x7fff4e78b6e0) at /home/matt/tmp/php-
5.2.11/main/main.c:2020
#6 0x0069100c in main (argc=4, argv=0x7fff4e78b8d8) at
/home/matt/tmp/php-5.2.11/sapi/cli/php_cli.c:1162
--
Edit bug report at http://bugs.php.net/?id=50207edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50207r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50207r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50207r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50207r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50207r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50207r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50207r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50207r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50207r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50207r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50207r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50207r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50207r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50207r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50207r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50207r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50207r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50207r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50207r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50207r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50207r=mysqlcfg
#50207 [Com]: segmentation fault when concatenating very large strings on 64bit linux
ID: 50207
Comment by: matt at bitwarehouse dot com
Reported By: matt at bitwarehouse dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: CentOS 5 x64
PHP Version: 5.2.11
New Comment:
Clarification. The reproduce code should be:
?php
// run me with: php -d memory_limit=-1
$s = str_repeat('A', pow(2,31));
$s .= 'B'; // fails with segfault
printf(strlen: %u last-char: %c, strlen($s), $s[pow(2,31)]);
?
Previous Comments:
[2009-11-17 18:27:41] matt at bitwarehouse dot com
Description:
When concatenating values to a string of length = 2^31, a segmentation
fault will occur in memcpy on 64 bit Linux. This appears to be caused
by the signed int length of the string (overflowed to negative) being
cast to unsigned long long when added to an 8 byte pointer in
Zend/zend_operators.c:concat_function.
This also occurs in PHP 5.3.0.
In PHP 5.1.6, a fatal erealloc error would be issued when the variable
hit (2^31)+1 (INT_MAX) to prevent overflow. This however is gone in
PHP
5.2.
It is also unclear if PHP and its string functions are supposed to
support strings larger than 2GB.
Reproduce code:
---
?php
// run me with: php -d memory_limit=-1
$s = str_repeat('A', pow(2,31));
$s .= 'B'; // fails with segfault
printf(strlen: %u last-char: %c, strlen($s), $s[pow(2,31)-1]);
?
Expected result:
Either:
strlen: 2147483649 last-char: B
-or-
FATAL: erealloc(): Unable to allocate XXX bytes
with the understanding that strings cannot contain more than 2^31 bytes
Actual result:
--
PHP 5.2.11 and 5.3.0 were compiled with no configure arguments, no
patches, no extra extensions on 64bit CentOS 5.
E.g. ./configure make
#presume a.php contains reproduce code
% ./sapi/cli/php -d memory_limit=-1 a.php
Segmentation fault
Backtrace of segfault:
Program received signal SIGSEGV, Segmentation fault.
0x003897a7bdc1 in memcpy () from /lib64/libc.so.6
(gdb) bt
#0 0x003897a7bdc1 in memcpy () from /lib64/libc.so.6
#1 0x0060a520 in concat_function (result=value optimized
out, op1=0x1c32ba60, op2=0x1c32c850) at /home/matt/tmp/php-
5.2.11/Zend/zend_operators.c:1208
#2 0x00676623 in zend_binary_assign_op_helper_SPEC_CV_CONST
(binary_op=0x60a3c0 concat_function, execute_data=0x7fff4e789070) at
/home/matt/tmp/php-5.2.11/Zend/zend_vm_execute.h:21034
#3 0x0062fd73 in execute (op_array=0x1c32c278) at
/home/matt/tmp/php-5.2.11/Zend/zend_vm_execute.h:92
#4 0x006117a3 in zend_execute_scripts (type=8,
retval=0x2b47b33ea030, file_count=3) at /home/matt/tmp/php-
5.2.11/Zend/zend.c:1134
#5 0x005d164b in php_execute_script
(primary_file=0x7fff4e78b6e0) at /home/matt/tmp/php-
5.2.11/main/main.c:2020
#6 0x0069100c in main (argc=4, argv=0x7fff4e78b8d8) at
/home/matt/tmp/php-5.2.11/sapi/cli/php_cli.c:1162
--
Edit this bug report at http://bugs.php.net/?id=50207edit=1
#49437 [Opn-Csd]: Can't disable LIBXML_NOENT option
ID: 49437 User updated by: matt at matthewfagan dot com Reported By: matt at matthewfagan dot com -Status: Open +Status: Closed Bug Type: SimpleXML related Operating System: ALL PHP Version: 5.2.10 New Comment: Scratch this. It seems to be a bug in the underlying libxml (they don't treat the predefined entities as entities), which also means that all the PHP functions based on libxml have the same problem. Still, it might be nice to add a comment to the documentation that the LIBXML_NOENT option does not apply to built-in XML entities, only to DTD-defined entities. Previous Comments: [2009-09-02 05:30:07] matt at matthewfagan dot com Description: One of the options to simplexml_load_string is LIBXML_NOENT. This option cannot be turned off. Reproduce code: --- The prototype for the simplexml_load_string function is: object simplexml_load_string ( string $data [, string $class_name=SimpleXMLElement [, int $options=0 [, string $ns [, bool $is_prefix=false ) Note the $options=0. However, it actually behaves like $options=LIBXML_NOENT. There is no way to disable this behavior. Explicitly specifying 0 does not turn off LIBXML_NOENT. Code to reproduce: echo simplexml_load_string(dataamp;/data, SimpleXMLElement, 0); Expected result: This should return amp;, because I have explicity turned off the LIBXML_NOENT option. However, amp; is converted to by libxml regardless of the specified options. It's as if the underlying C code is calling: libxml-load_string(data, classname, options | LIBXML_NOENT); (Note: not the real function names...) Actual result: -- Resolution: There would seem to be two resolutions. Either: a) Change the prototype so that the default value of $options is LIBXML_NOENT, allowing this to be overridden by specifying the options. OR b) Create a special LIBXML flag especially for PHP, such as LIBXML_KEEPENT that negates the LIBXML_NOENT flag. Note: This is not an important bug for me, because I will just ditch using SimpleXML and find another way, but I think it should still be on the books as a bug. -- Edit this bug report at http://bugs.php.net/?id=49437edit=1
#49437 [NEW]: Can't disable LIBXML_NOENT option
From: matt at matthewfagan dot com Operating system: ALL PHP version: 5.2.10 PHP Bug Type: SimpleXML related Bug description: Can't disable LIBXML_NOENT option Description: One of the options to simplexml_load_string is LIBXML_NOENT. This option cannot be turned off. Reproduce code: --- The prototype for the simplexml_load_string function is: object simplexml_load_string ( string $data [, string $class_name=SimpleXMLElement [, int $options=0 [, string $ns [, bool $is_prefix=false ) Note the $options=0. However, it actually behaves like $options=LIBXML_NOENT. There is no way to disable this behavior. Explicitly specifying 0 does not turn off LIBXML_NOENT. Code to reproduce: echo simplexml_load_string(dataamp;/data, SimpleXMLElement, 0); Expected result: This should return amp;, because I have explicity turned off the LIBXML_NOENT option. However, amp; is converted to by libxml regardless of the specified options. It's as if the underlying C code is calling: libxml-load_string(data, classname, options | LIBXML_NOENT); (Note: not the real function names...) Actual result: -- Resolution: There would seem to be two resolutions. Either: a) Change the prototype so that the default value of $options is LIBXML_NOENT, allowing this to be overridden by specifying the options. OR b) Create a special LIBXML flag especially for PHP, such as LIBXML_KEEPENT that negates the LIBXML_NOENT flag. Note: This is not an important bug for me, because I will just ditch using SimpleXML and find another way, but I think it should still be on the books as a bug. -- Edit bug report at http://bugs.php.net/?id=49437edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49437r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49437r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49437r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49437r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49437r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49437r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49437r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49437r=needscript Try newer version: http://bugs.php.net/fix.php?id=49437r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49437r=support Expected behavior: http://bugs.php.net/fix.php?id=49437r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49437r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49437r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49437r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49437r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49437r=dst IIS Stability: http://bugs.php.net/fix.php?id=49437r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49437r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49437r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49437r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49437r=mysqlcfg
#49377 [NEW]: number_format and decimal numbers
From: matt at mx-dev dot net Operating system: Windows PHP version: 5.2.10 PHP Bug Type: Math related Bug description: number_format and decimal numbers Description: I've encountered a bug using the number_format function with a high decimal value. Actually, an approximative number appear randomly if the decimal number is greater than 30. I think that the bug can be reproduced being a little bit sticky. I succeeded to reproduce this bug with the following code : number_format(25, 49, ',', ' '); Reproduce code: --- echo number_format(15, 50, ',', ' '); Expected result: 15,00 Actual result: -- 14,99822364316059974953532218933105468750 -- Edit bug report at http://bugs.php.net/?id=49377edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49377r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49377r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49377r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49377r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49377r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49377r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49377r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49377r=needscript Try newer version: http://bugs.php.net/fix.php?id=49377r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49377r=support Expected behavior: http://bugs.php.net/fix.php?id=49377r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49377r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49377r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49377r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49377r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49377r=dst IIS Stability: http://bugs.php.net/fix.php?id=49377r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49377r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49377r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49377r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49377r=mysqlcfg
#49197 [Bgs]: FILTER_VALIDATE_URL does not validate urls
ID: 49197 User updated by: matt dot farina at gmail dot com Reported By: matt dot farina at gmail dot com Status: Bogus Bug Type:Filter related PHP Version: 5.2.10 New Comment: The documentation at http://www.php.net/manual/en/filter.filters.validate.php states that it Validates value as URL, optionally with required components. It does not validate it to be a url. I setup a simple test and it validated invalid urls. I may not have reported it properly through your process and it may not be the best solution but this is a bug. Either a documentation bug or a functionality bug. This is not proper validation! Previous Comments: [2009-08-09 12:56:51] il...@php.net 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 . [2009-08-08 14:32:15] matt dot farina at gmail dot com Description: FILTER_VALIDATE_URL doesn't actually validate a url. It passes the url through parse_url (which according to the documentation is not meant to validate a url). When tested against a test set this can be seen. Instead of this method PHP should use a regex or some other method to actually validate it. See http://api.drupal.org/api/function/valid_url/6 for an example that is to RFC 3986. I would hope for PHP 6 we can have it look for a valid IRL (with international characters) as well. -- Edit this bug report at http://bugs.php.net/?id=49197edit=1
#49197 [NEW]: FILTER_VALIDATE_URL does not validate urls
From: matt dot farina at gmail dot com Operating system: PHP version: 5.2.10 PHP Bug Type: Filter related Bug description: FILTER_VALIDATE_URL does not validate urls Description: FILTER_VALIDATE_URL doesn't actually validate a url. It passes the url through parse_url (which according to the documentation is not meant to validate a url). When tested against a test set this can be seen. Instead of this method PHP should use a regex or some other method to actually validate it. See http://api.drupal.org/api/function/valid_url/6 for an example that is to RFC 3986. I would hope for PHP 6 we can have it look for a valid IRL (with international characters) as well. -- Edit bug report at http://bugs.php.net/?id=49197edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49197r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49197r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49197r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49197r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49197r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49197r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49197r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49197r=needscript Try newer version: http://bugs.php.net/fix.php?id=49197r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49197r=support Expected behavior: http://bugs.php.net/fix.php?id=49197r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49197r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49197r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49197r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49197r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49197r=dst IIS Stability: http://bugs.php.net/fix.php?id=49197r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49197r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49197r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49197r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49197r=mysqlcfg
#48206 [NEW]: Segfault in RecursiveIteratorIterator::current()
From: matt at raines dot me dot uk Operating system: Linux ubuntu 2.6.27-7-generic #1 PHP version: 5.3CVS-2009-05-09 (snap) PHP Bug Type: Reproducible crash Bug description: Segfault in RecursiveIteratorIterator::current() Description: If you wrap a RecursiveArrayIterator in a RecursiveIteratorIterator and iterate past the end of the array, PHP crashes. Reproduce code: --- ?php $i = new RecursiveIteratorIterator(new RecursiveArrayIterator(array())); $i-next(); var_dump($i-current()); ? Expected result: NULL Actual result: -- Segmentation fault (core dumped) -- Edit bug report at http://bugs.php.net/?id=48206edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48206r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48206r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48206r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48206r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48206r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48206r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48206r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48206r=needscript Try newer version: http://bugs.php.net/fix.php?id=48206r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48206r=support Expected behavior: http://bugs.php.net/fix.php?id=48206r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48206r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48206r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48206r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48206r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48206r=dst IIS Stability: http://bugs.php.net/fix.php?id=48206r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48206r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48206r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48206r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48206r=mysqlcfg
#46600 [Com]: _empty_ key in objects (see #41504)
ID: 46600
Comment by: matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Feedback
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
A note about this in the json_decode page would be appreciated. Perhaps
a strict mode flag, so that it can fail if it cannot be decoded as an
object (?). For the moment the only safe way to decode json is into
arrays.
The _empty_ behavior I thought was a bug (as it was with arrays) is a
required behavior for objects (at least without __get __set in a
wrapper class).
The bugs that jump out at me now can be seen with the code below... you
can create objects with unreachable properties. If that blank property
access is fixed, then this becomes not so much of an issue. Or it should
be stopped from ever happening... silent errors bite us all.
Illegal Member variable name if var_dump does it, fatal if a user does
it.
Notice: PHPDocument1 line 8 - Illegal member variable name
?
$blank = '';
$another = ' another';
$a = array($blank=1234, 'some other key'=5678, $another=);
$b = (object) $a;
$c = json_decode(json_encode($a));
var_dump($b);
var_dump($c);
#echo $b-$blank; //fatal
echo $b-$another; //works
#echo $c-$blank; //fatal
echo $c-$another; //works
?
Previous Comments:
[2008-12-18 03:27:25] scott...@php.net
I'm not even sure what the bug is? You can't have an empty property
name hence the use of _empty_.
The key collision thing is a very edge case, are you saying you ran
into this in a real life usage?
The best course of action may be to have this documented on the
json_encode() and json_decode() pages.
[2008-12-04 20:39:13] Matt at mpcm dot com
Thanx for the reply magicaltux, `Feature` is an interesting word
considering the possible key collision.
There are other ways to get things that are not strictly objects to
behave that way. Overloading (like example #1 at
http://us.php.net/manual/en/language.oop5.overloading.php). It works
well enough as long as you also make it iterate correctly.
What I am suggesting is that it is better to fail in decoding into an
object, than to silently cause a key collision.
Or alternatively, produce an overloaded object which can have these
keys (by default, or passed optional flag) from json_decode. It's an
opinion, but a wrapper gets me where I need to be for now, and I'm
pretty sure this is an edge case.
$a = '{:a,_empty_:b}';
echo json_encode(json_decode($a));
echo json_encode(json_decode($a, true));
output:
{_empty_:b}
{:a,_empty_:b}
for some values:
$a != json_encode(json_decode($a));
[2008-12-04 10:44:29] magical...@php.net
I believe this is not a bug, but a feature.
An object *can't* have an empty property (while an array can).
If you want to use json_decode() with json containing empty key, either
access those empty key using special keyword _empty_, or put the
optionnal $assoc parameter of json_decode() to true to get result as an
array.
If you want objects to support empty keys, I believe this is not going
to happen soon, as this is enforced by a specific error message.
Fatal error: Cannot access empty property in php shell code on line 1
Please note that a property name starting with NULL character won't
work either.
[2008-11-18 17:35:30] matt at mpcm dot com
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
?
$key = ;
$o = (object) array($key=4,example=8);
var_dump($o);
print 'blank key test:' . (isset($o-$key)?'true':'false');
print $o-{$key};
var_dump($o-$key);
?
output:
object(stdClass)#1 (2) {
[]=
int(4)
[example]=
int(8)
}
blank key test:falsebr /
bFatal error/b: Cannot access empty property in
bPHPDocument1/b on line b8/bbr /
All throws Notice: line 4 - Illegal member variable name
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
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/46600
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46600 [Ver]: _empty_ key in objects (see #41504)
ID: 46600
User updated by: Matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
Thanx for the reply magicaltux, `Feature` is an interesting word
considering the possible key collision.
There are other ways to get things that are not strictly objects to
behave that way. Overloading (like example #1 at
http://us.php.net/manual/en/language.oop5.overloading.php). It works
well enough as long as you also make it iterate correctly.
What I am suggesting is that it is better to fail in decoding into an
object, than to silently cause a key collision.
Or alternatively, produce an overloaded object which can have these
keys (by default, or passed optional flag) from json_decode. It's an
opinion, but a wrapper gets me where I need to be for now, and I'm
pretty sure this is an edge case.
$a = '{:a,_empty_:b}';
echo json_encode(json_decode($a));
echo json_encode(json_decode($a, true));
output:
{_empty_:b}
{:a,_empty_:b}
for some values:
$a != json_encode(json_decode($a));
Previous Comments:
[2008-12-04 10:44:29] [EMAIL PROTECTED]
I believe this is not a bug, but a feature.
An object *can't* have an empty property (while an array can).
If you want to use json_decode() with json containing empty key, either
access those empty key using special keyword _empty_, or put the
optionnal $assoc parameter of json_decode() to true to get result as an
array.
If you want objects to support empty keys, I believe this is not going
to happen soon, as this is enforced by a specific error message.
Fatal error: Cannot access empty property in php shell code on line 1
Please note that a property name starting with NULL character won't
work either.
[2008-11-18 17:35:30] matt at mpcm dot com
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
?
$key = ;
$o = (object) array($key=4,example=8);
var_dump($o);
print 'blank key test:' . (isset($o-$key)?'true':'false');
print $o-{$key};
var_dump($o-$key);
?
output:
object(stdClass)#1 (2) {
[]=
int(4)
[example]=
int(8)
}
blank key test:falsebr /
bFatal error/b: Cannot access empty property in
bPHPDocument1/b on line b8/bbr /
All throws Notice: line 4 - Illegal member variable name
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46600 [Com]: _empty_ key in objects (see #41504)
ID: 46600
Comment by: matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
Previous Comments:
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46600 [Com]: _empty_ key in objects (see #41504)
ID: 46600
Comment by: matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
?
$key = ;
$o = (object) array($key=4,example=8);
var_dump($o);
print 'blank key test:' . (isset($o-$key)?'true':'false');
print $o-{$key};
var_dump($o-$key);
?
output:
object(stdClass)#1 (2) {
[]=
int(4)
[example]=
int(8)
}
blank key test:falsebr /
bFatal error/b: Cannot access empty property in
bPHPDocument1/b on line b8/bbr /
All throws Notice: line 4 - Illegal member variable name
Previous Comments:
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46600 [NEW]: _empty_ key in objects (see #41504)
From: Matt at mpcm dot com
Operating system: Ubuntu
PHP version: 5.3.0alpha2
PHP Bug Type: JSON related
Bug description: _empty_ key in objects (see #41504)
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit bug report at http://bugs.php.net/?id=46600edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46600r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46600r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46600r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46600r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46600r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46600r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46600r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46600r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46600r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46600r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46600r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46600r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46600r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46600r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46600r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46600r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46600r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46600r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46600r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46600r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46600r=mysqlcfg
#45915 [Opn]: xmlrpc_encode_request does not encode numeric keys properly
ID: 45915 User updated by: matt at waggoner dot com Reported By: matt at waggoner dot com Status: Open -Bug Type: Feature/Change Request +Bug Type: XMLRPC-EPI related Operating System: * PHP Version: 5.2.6 New Comment: Any word on this? I wonder if this one's getting ignored because it doesn't show up in the bug search. Previous Comments: [2008-08-25 21:26:08] matt at waggoner dot com Description: This issue has been marked as bogus or wontfix before, but I believe this is a bad idea and that this issue should be fixed. Bug #21949 ends with this comment: Not a bug, XML-RPC is ambigous as to the value that the name field can contain. However, all indications point to it being a string value, in XML this represents a value that is non-numeric. This is false; XML's string type is not restricted to non-numeric values. http://www.w3.org/TR/xmlschema-2/#string says that a string's value space is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production. The Char production is the following grammar: char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] The characters 0-9 are within the [#x20-#xD7FF] range, ergo the string XML datatype can validly contain a set of only numeric characters such as 123, which eliminates that objection. The XML-RPC spec does indeed not specify what value a name element may contain, but it seems fairly useless to simply drop numeric keys; a string is a string regardless of whether it contains letters or not. Re bug #37746: It has been this way for a long time is not a valid reason to avoid fixing this (see any number of longstanding bugs in PHP's history); this might break existing code is also not a valid reason (see any number of backward-incompatible changes in PHP's history). Please fix this bug. Reproduce code: --- See bugs #21949 and #37746. -- Edit this bug report at http://bugs.php.net/?id=45915edit=1
#46139 [Com]: PDOStatement-setFetchMode() forgets FETCH_PROPS_LATE
ID: 46139
Comment by: matt at mattfarina dot com
Reported By: chsc at peytz dot dk
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3.0alpha2
New Comment:
I've found this same problem in PHP 5.2.6.
Previous Comments:
[2008-09-20 19:46:57] chsc at peytz dot dk
Suggested fix:
Index: ext/pdo/pdo_stmt.c
===
RCS file: /repository/php-src/ext/pdo/pdo_stmt.c,v
retrieving revision 1.118.2.38.2.24.2.22
diff -u -8 -p -r1.118.2.38.2.24.2.22 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 12 Aug 2008 17:20:25 -
1.118.2.38.2.24.2.22
+++ ext/pdo/pdo_stmt.c 20 Sep 2008 19:44:43 -
@@ -902,24 +902,25 @@ static int do_fetch_opt_finish(pdo_stmt_
}
/* }}} */
/* perform a fetch. If do_bind is true, update any bound columns.
* If return_value is not null, store values into it according to HOW.
*/
static int do_fetch(pdo_stmt_t *stmt, int do_bind, zval
*return_value,
enum pdo_fetch_type how, enum pdo_fetch_orientation ori, long
offset, zval *return_all TSRMLS_DC) /* {{{ */
{
- int flags = how PDO_FETCH_FLAGS, idx, old_arg_count = 0;
+ int flags, idx, old_arg_count = 0;
zend_class_entry *ce = NULL, *old_ce = NULL;
zval grp_val, *grp, **pgrp, *retval, *old_ctor_args = NULL;
int colno;
if (how == PDO_FETCH_USE_DEFAULT) {
how = stmt-default_fetch_type;
}
+ flags = how PDO_FETCH_FLAGS;
how = how ~PDO_FETCH_FLAGS;
if (!do_fetch_common(stmt, ori, offset, do_bind TSRMLS_CC)) {
return 0;
}
if (how == PDO_FETCH_BOUND) {
RETVAL_TRUE;
Inspired by the fix for bug 41971:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo/pdo_stmt.c?r1=1.118.2.38.2.21r2=1.118.2.38.2.22
[2008-09-20 19:43:53] chsc at peytz dot dk
Description:
PDO::FETCH_PROPS_LATE only works if it specified in both the
$stmt-setFetchMode() call and in the following $stmt-fetch().
Calling
$stmt-setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt-fetch();
yields the same result as
$stmt-setFetchMode(PDO::FETCH_CLASS, 'MyClass');
$obj$stmt-fetch();
In order to make it work you should specify FETCH_PROPS_LATE in both
calls, i.e.
$stmt-setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt-fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
Reproduce code:
---
class Person {
public $name = NULL;
public function __construct() {
var_dump($this-name);
}
}
$db = new PDO(mysql:dbname=foo, foo, secret);
$db-exec(CREATE TABLE person (id INTEGER NOT NULL, name
VARCHAR(100)));
$db-exec(INSERT INTO person (id, name) VALUES (1, 'Sven'));
$stmt1 = $db-query('SELECT * FROM person');
$stmt1-setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj1 = $stmt1-fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
var_dump($obj1-name);
$stmt1 = NULL;
$stmt2 = $db-query('SELECT * FROM person');
$stmt2-setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj2 = $stmt2-fetch();
var_dump($obj2-name);
Expected result:
NULL
string(4) Sven
NULL
string(4) Sven
Actual result:
--
NULL
string(4) Sven
string(4) Sven
string(4) Sven
--
Edit this bug report at http://bugs.php.net/?id=46139edit=1
#43402 [Com]: FILTER_VALIDATE_EMAIL is not RFC2822 compliant
ID: 43402
Comment by: matt at mattfarina dot com
Reported By: nobody at example dot org
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.5
New Comment:
RFC 2822 allows for email addresses like [EMAIL PROTECTED] or
[EMAIL PROTECTED] But, RFC 2821 (SMTP Standard) does not allow for those.
See sections 4.1.2 and 4.13 for more detail.
The question with email addresses is should we support RFC 2822 or
2821? For routing FILTER_VALIDATE_EMAIL currently follows RFC 2821.
Previous Comments:
[2008-09-16 20:00:59] matt at mattfarina dot com
Please correct me if I'm wrong but isn't localhost an alias and RFC
2822 requires a fully qualified domain name or IP address. That would be
the issue with [EMAIL PROTECTED]
[2008-09-16 19:37:41] drewish at katherinehouse dot com
The current code also bounces valid email addresses like
[EMAIL PROTECTED]. I haven't been able to test out the suggested regex.
[2007-11-26 14:23:55] nobody at example dot org
Updated test, php_filter_validate_email() returns string on success.
Surely bool would be a more appropriate return value for a logic filter?
Updated regex above fixes the specific issue I was having, I'm
uncertain about other edge cases ([EMAIL PROTECTED]@example.org)?
--TEST--
Bug 43402, RFC2822 allows chars (?, =) in dot-atoms
--SKIPIF--
?php if (!extension_loaded(filter)) die(skip); ?
--FILE--
?php
$var=!#$%'*+-/=.?^_`{|[EMAIL PROTECTED];
var_dump((bool)filter_var($var, FILTER_VALIDATE_EMAIL));
?
--EXPECT--
bool(true)
[2007-11-26 11:34:19] nobody at example dot org
I may be missing something about the unit tests, following regex update
to php_filter_validate_email() will not pass my test case (after doing
rm ext/filter/tests/*.o ext/filter/tests/*.lo, clearing .out .log .exp
.diff from tests and doing make; make test).
const char regexp[] =
/^((\\\[^\f\\n\\r\\t\\b]+\\\)|([\\w\\!\\#\\$\\%'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+(\\.[\\w\\!\\#\\$\\%'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/D;
Yet the equivalent regex works as expected in both PHP and my patched
install.
?php
error_reporting(E_ALL|E_STRICT);
function validate_email($_)
{
/* Original from PEAR QuickForm Email.php rev: 1.4 */
$r =
'/^((\[^\\f\n\r\t\v\b]+\)|([\w\!\#\$\%\\'\*\+\-\~\/\^\`\|\{\}\=\?]+(\.[\w\!\#\$\%\\'\*\+\-\~\/\^\`\|\{\}\=\?]+)*))@((\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\-])+\.)+[A-Za-z\-]+))$/D';
return (bool) preg_match($r, $_);
}
$test = array('[EMAIL PROTECTED]'=true,
'[EMAIL PROTECTED]'=false,
!#$%'*+-/=.?^_`{|[EMAIL PROTECTED]=true,
);
$failed = 0;
$fail = array();
foreach ($test as $k = $v){
if (!(validate_email($k) === $v)){
$failed++;
$fail[].= $k;
}
}
if ($failed 0){
echo Failed $failed of ,count($test), tests using PHP func\n;
print_r($fail);
}
$failed = 0;
$fail = array();
foreach ($test as $k = $v){
if (!((bool)filter_var($k, FILTER_VALIDATE_EMAIL) == (bool)$v)){
$failed++;
$fail[].= $k;
}
}
if ($failed 0){
echo Failed $failed of ,count($test), tests using filter
func\n;
print_r($fail);
}
[2007-11-25 23:46:34] nobody at example dot org
--TEST--
RFC2822 conformance for local atoms
--SKIPIF--
?php if (!extension_loaded(filter)) die(skip); ?
--FILE--
?php
$var = !#$%'*+-/=.?^_`{|[EMAIL PROTECTED];
var_dump(filter_var($var, FILTER_VALIDATE_EMAIL));
?
--EXPECT--
bool(true)
# Apologies for bug spam
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/43402
--
Edit this bug report at http://bugs.php.net/?id=43402edit=1
#43402 [Com]: FILTER_VALIDATE_EMAIL is not RFC2822 compliant
ID: 43402
Comment by: matt at mattfarina dot com
Reported By: nobody at example dot org
Status: Open
Bug Type: Filter related
Operating System: *
PHP Version: 5.2.5
New Comment:
Please correct me if I'm wrong but isn't localhost an alias and RFC
2822 requires a fully qualified domain name or IP address. That would be
the issue with [EMAIL PROTECTED]
Previous Comments:
[2008-09-16 19:37:41] drewish at katherinehouse dot com
The current code also bounces valid email addresses like
[EMAIL PROTECTED]. I haven't been able to test out the suggested regex.
[2007-11-26 14:23:55] nobody at example dot org
Updated test, php_filter_validate_email() returns string on success.
Surely bool would be a more appropriate return value for a logic filter?
Updated regex above fixes the specific issue I was having, I'm
uncertain about other edge cases ([EMAIL PROTECTED]@example.org)?
--TEST--
Bug 43402, RFC2822 allows chars (?, =) in dot-atoms
--SKIPIF--
?php if (!extension_loaded(filter)) die(skip); ?
--FILE--
?php
$var=!#$%'*+-/=.?^_`{|[EMAIL PROTECTED];
var_dump((bool)filter_var($var, FILTER_VALIDATE_EMAIL));
?
--EXPECT--
bool(true)
[2007-11-26 11:34:19] nobody at example dot org
I may be missing something about the unit tests, following regex update
to php_filter_validate_email() will not pass my test case (after doing
rm ext/filter/tests/*.o ext/filter/tests/*.lo, clearing .out .log .exp
.diff from tests and doing make; make test).
const char regexp[] =
/^((\\\[^\f\\n\\r\\t\\b]+\\\)|([\\w\\!\\#\\$\\%'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+(\\.[\\w\\!\\#\\$\\%'\\*\\+\\-\\~\\/\\^\\`\\|\\{\\}\\=\\?]+)*))@((\\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\\-])+\\.)+[A-Za-z\\-]+))$/D;
Yet the equivalent regex works as expected in both PHP and my patched
install.
?php
error_reporting(E_ALL|E_STRICT);
function validate_email($_)
{
/* Original from PEAR QuickForm Email.php rev: 1.4 */
$r =
'/^((\[^\\f\n\r\t\v\b]+\)|([\w\!\#\$\%\\'\*\+\-\~\/\^\`\|\{\}\=\?]+(\.[\w\!\#\$\%\\'\*\+\-\~\/\^\`\|\{\}\=\?]+)*))@((\[(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))\])|(((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9]))\.((25[0-5])|(2[0-4][0-9])|([0-1]?[0-9]?[0-9])))|((([A-Za-z0-9\-])+\.)+[A-Za-z\-]+))$/D';
return (bool) preg_match($r, $_);
}
$test = array('[EMAIL PROTECTED]'=true,
'[EMAIL PROTECTED]'=false,
!#$%'*+-/=.?^_`{|[EMAIL PROTECTED]=true,
);
$failed = 0;
$fail = array();
foreach ($test as $k = $v){
if (!(validate_email($k) === $v)){
$failed++;
$fail[].= $k;
}
}
if ($failed 0){
echo Failed $failed of ,count($test), tests using PHP func\n;
print_r($fail);
}
$failed = 0;
$fail = array();
foreach ($test as $k = $v){
if (!((bool)filter_var($k, FILTER_VALIDATE_EMAIL) == (bool)$v)){
$failed++;
$fail[].= $k;
}
}
if ($failed 0){
echo Failed $failed of ,count($test), tests using filter
func\n;
print_r($fail);
}
[2007-11-25 23:46:34] nobody at example dot org
--TEST--
RFC2822 conformance for local atoms
--SKIPIF--
?php if (!extension_loaded(filter)) die(skip); ?
--FILE--
?php
$var = !#$%'*+-/=.?^_`{|[EMAIL PROTECTED];
var_dump(filter_var($var, FILTER_VALIDATE_EMAIL));
?
--EXPECT--
bool(true)
# Apologies for bug spam
[2007-11-25 22:22:59] nobody at example dot org
Description:
The regex used in php_filter_validate_email does not permit all valid
atom chars from RFC2822 (eg: ASCII 61, 63).
Reproduce code:
---
?php
$valid=!#$%'*+-/=.?^_`{|[EMAIL PROTECTED];
echo filter_var($valid, FILTER_VALIDATE_EMAIL)? 'Valid': 'Invalid',
\n;
Expected result:
Valid
Actual result:
--
Invalid
--
Edit this bug report at http://bugs.php.net/?id=43402edit=1
#45915 [NEW]: xmlrpc_encode_request does not encode numeric keys properly
From: matt at waggoner dot com Operating system: All PHP version: 5.2.6 PHP Bug Type: XMLRPC-EPI related Bug description: xmlrpc_encode_request does not encode numeric keys properly Description: This issue has been marked as bogus or wontfix before, but I believe this is a bad idea and that this issue should be fixed. Bug #21949 ends with this comment: Not a bug, XML-RPC is ambigous as to the value that the name field can contain. However, all indications point to it being a string value, in XML this represents a value that is non-numeric. This is false; XML's string type is not restricted to non-numeric values. http://www.w3.org/TR/xmlschema-2/#string says that a string's value space is the set of finite-length sequences of characters (as defined in [XML 1.0 (Second Edition)]) that match the Char production. The Char production is the following grammar: char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] The characters 0-9 are within the [#x20-#xD7FF] range, ergo the string XML datatype can validly contain a set of only numeric characters such as 123, which eliminates that objection. The XML-RPC spec does indeed not specify what value a name element may contain, but it seems fairly useless to simply drop numeric keys; a string is a string regardless of whether it contains letters or not. Re bug #37746: It has been this way for a long time is not a valid reason to avoid fixing this (see any number of longstanding bugs in PHP's history); this might break existing code is also not a valid reason (see any number of backward-incompatible changes in PHP's history). Please fix this bug. Reproduce code: --- See bugs #21949 and #37746. -- Edit bug report at http://bugs.php.net/?id=45915edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45915r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45915r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45915r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45915r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45915r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45915r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45915r=needscript Try newer version:http://bugs.php.net/fix.php?id=45915r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45915r=support Expected behavior:http://bugs.php.net/fix.php?id=45915r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45915r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45915r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45915r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45915r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45915r=dst IIS Stability:http://bugs.php.net/fix.php?id=45915r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45915r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45915r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45915r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45915r=mysqlcfg
#45822 [NEW]: Invalid value passed to StrToTime crashes W3WP process
From: matt at neimeyer dot org Operating system: Windows 2003 PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: Invalid value passed to StrToTime crashes W3WP process Description: Using a stock installation of PHP 5.2.6 (or 5.2.5 or 5.2.3) as an ISAPI module on Windows 2003 Standard Edition x32 (fully updated using Windows Update), if you pass a wacky value to strtotime the w3wp.exe (IIS Worker Pool) spikes to 99% and crashes the web server. We accidentally used date(-24 hours) instead of strtotime(-24 hours) and then passed that (via some intermediary function calls) to strtotime. It does not crash on Win2003 SE x64 (or any other operating system that we run this application on). I am aware of other w3wp.exe bugs being reported but those do not seem to match this specific cause. Similarly, strtotime bugs don't seem to match. Reproduce code: --- echo strtotime(date(-24 hours)); Expected result: Return false or -1 (with the caveat that I know it's bad code on my part) Actual result: -- w3wp.exe crashes as soon as the page starts to load. Watching in task manager on the web server, you can see w3wp.exe spike to 99% then stay there. If you kill the task the web server behaves oddly, generating Service Unavailable results to the end browser until the World Wide Web Publishing Service is restarted. -- Edit bug report at http://bugs.php.net/?id=45822edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45822r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45822r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45822r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45822r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45822r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45822r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45822r=needscript Try newer version:http://bugs.php.net/fix.php?id=45822r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45822r=support Expected behavior:http://bugs.php.net/fix.php?id=45822r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45822r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45822r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45822r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45822r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45822r=dst IIS Stability:http://bugs.php.net/fix.php?id=45822r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45822r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45822r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45822r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45822r=mysqlcfg
#44117 [Opn-Bgs]: SOAP fault, appears that function doesn't exist
ID: 44117
User updated by: matt at warnockinc dot com
Reported By: matt at warnockinc dot com
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Redhat EL5 64-bit
PHP Version: 5.2.5
New Comment:
appears to be a problem in the WSDL file. sorry for the inconvenience.
Previous Comments:
[2008-02-14 05:39:22] matt at warnockinc dot com
Description:
I am writing a script and keep getting an error. It appears that the
function logout doesn't exist, however it is in the server, and in the
WSDL. I removed everything but the function, and can reproduce the
error
Reproduce code:
---
server:
$server = new SoapServer( 'ws.wsdl', array('uri' =
urn://www.herong.home/res)
);
$server-SetClass('ws');
$server-handle();
class ws
{
/**
* logout method
*
* @param string $sessionkey sessionKey
* @return string status status
*/
function logout ( $sessionkey )
{
return true;
}
}
Client:
$client = new SoapClient(null, array(
'location' = http://localhost/testserver.php;,
'uri' = urn://www.herong.home/req,
'trace'= 1 ));
$return =
$client-__soapCall(logout,array(04cbf12ab33ccf7710c24ef7f59699393371f319));
print_r( $return );
Expected result:
i should see true
Actual result:
--
Fatal error: Uncaught SoapFault exception: [SOAP-ENV:Server] Procedure
'logout' not present in /home/user/public_html/Dunbar/testclient.php:9
Stack trace: #0 /home/user/public_html/Dunbar/testclient.php(9):
SoapClient-__soapCall('logout', Array) #1 {main} thrown in
/home/user/public_html/Dunbar/testclient.php on line 9
--
Edit this bug report at http://bugs.php.net/?id=44117edit=1
#44117 [NEW]: SOAP fault, appears that function doesn't exist
From: matt at warnockinc dot com
Operating system: Redhat EL5 64-bit
PHP version: 5.2.5
PHP Bug Type: Reproducible crash
Bug description: SOAP fault, appears that function doesn't exist
Description:
I am writing a script and keep getting an error. It appears that the
function logout doesn't exist, however it is in the server, and in the
WSDL. I removed everything but the function, and can reproduce the error
Reproduce code:
---
server:
$server = new SoapServer( 'ws.wsdl', array('uri' =
urn://www.herong.home/res)
);
$server-SetClass('ws');
$server-handle();
class ws
{
/**
* logout method
*
* @param string $sessionkey sessionKey
* @return string status status
*/
function logout ( $sessionkey )
{
return true;
}
}
Client:
$client = new SoapClient(null, array(
'location' = http://localhost/testserver.php;,
'uri' = urn://www.herong.home/req,
'trace'= 1 ));
$return =
$client-__soapCall(logout,array(04cbf12ab33ccf7710c24ef7f59699393371f319));
print_r( $return );
Expected result:
i should see true
Actual result:
--
Fatal error: Uncaught SoapFault exception: [SOAP-ENV:Server] Procedure
'logout' not present in /home/user/public_html/Dunbar/testclient.php:9
Stack trace: #0 /home/user/public_html/Dunbar/testclient.php(9):
SoapClient-__soapCall('logout', Array) #1 {main} thrown in
/home/user/public_html/Dunbar/testclient.php on line 9
--
Edit bug report at http://bugs.php.net/?id=44117edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=44117r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44117r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44117r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44117r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44117r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44117r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44117r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44117r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44117r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44117r=support
Expected behavior:http://bugs.php.net/fix.php?id=44117r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44117r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44117r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44117r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=44117r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=44117r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44117r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44117r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44117r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44117r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44117r=mysqlcfg
#39375 [Com]: PHP Warning: imap_fetchstructure(): No body information available in a.php
ID: 39375 Comment by: matt at educause dot edu Reported By: queences dot sam at tallysolutions dot com Status: No Feedback Bug Type: IMAP related Operating System: linux PHP Version: 5.2.0 New Comment: I'm experiencing this issue too ... using IMAP ... using IIS/FastCGI ... PHP 5.2.5 Previous Comments: [2006-11-16 01:00:01] 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. [2006-11-08 13:59:54] [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. [2006-11-04 11:03:04] queences dot sam at tallysolutions dot com Description: While tring to process mails from the mailbox using imap function at times we encounter this error. But the mail number etc everything that it picks up is correct. Below given line is the exact error that we get: PHP Warning: imap_fetchstructure(): No body information available in /var/www/html/tallyweb/modules/forums/intranet/CRecvMailProcessMgr.php on line 1044 We have noticed that the error goes of once we restart the services - sendmail, httpd mysql. Please let us know if this is already a noted bug in PHP imap library. When is it going to be resolved. Queences -- Edit this bug report at http://bugs.php.net/?id=39375edit=1
#39858 [Com]: Lost connection to MySQL server during query by a repeated call stored proced
ID: 39858
Comment by: matt dot keeble at gmail dot com
Reported By: develar at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.0
Assigned To: wez
New Comment:
As an update to this, I'm not sure that this is a bug in PHP at all - I
believe it's a bug with MySQL. Have stumbled across this bug report
today after receiving MySQL lost connections from the MySQL command
line, and from Navicat Terminal - in both cases there was no PHP
involved at all, just an SP that calls a function in a loop which
subsequently calls another function. The SP returns the first row, but
then dies with the error message and goes into an irretrievable loop (in
Navicat).
Don't know if this will help, but thought I would share...
Previous Comments:
[2007-06-21 12:58:38] timo at hhesse dot de
Well, this is very disappointing. A new PHP version is out and this
stupid bug has not been fixed although a solution seems to be found by
mike at we11er dot co dot uk.
I can't use PHP5 without this hacked dll on our servers. Seems like no
one feels responsible for developers on windows servers.
There's no bug on linux so what are you talking about...?
[2007-05-18 21:12:31] paulsidekick at gmail dot com
I am still not able to issue two stored procedures in a row using PDO
and mysql 5.0.31, php 5.2.1 and windows server 2003 when using the php
pdo_mysql.dll extension. Is there any fix for this planned? It has
been a very long time since it was first noted. If there is a solution
other than using a hacked DLL with no source code, can somebody please
advice. This is the simplest way to see it happen.
$stmt = $myPdoConnection-query(CALL myStoredProc ('x', 'y'));
//this returns results
print_r($stmt-fetchAll());
//this does not - says mysql lost connection
print_r($stmt-fetchAll());
If I do this with SELECT statements instead I get no problem. I
believe that there is an additional row set send back with stored
procedures from mysql that needs to be interated over in order to issue
the next statement. However, I cannot access them with
$stmt-nextRowset();
as I get Warning: PDOStatement::nextRowset()
[function.PDOStatement-nextRowset]: SQLSTATE[HYC00]: Optional feature
not implemented in
Please help.
[2007-04-09 19:13:53] jaylehvee at srgtampa dot com
I am using this modified DLL, above, and it works great, in most
regards. The core issue still exists, however. Mulitple calls to stored
procedures are still causing db connection loss. I've had to go
lazy-load kuh-ray-zee on my objects to avoid connection failures. I
shouldn't have to use the wrong patterns in order to work around a
faulty db driver.
Mike, any chance you can post your hacked source somewhere?
[2007-03-26 19:57:43] timo at hhesse dot de
Hi mike, thanks for the fixed php_pdo_mysql.dll! I tested it right now
and it works perfectly!
It took me quite the whole day finding out that it was a php bug what
made my stored procedures producing those exceptions (on Windows IIS).
But now I'm asking myself if your fix will find its way into the next
PHP release so that I can be sure my code will work at my customers
Windows servers too or if I should use some script language that
supports stored procedures as they are meant...
A reliable answer in this issue would be great! ;-)
[2007-03-09 13:24:09] mike at we11er dot co dot uk
Hi everyone. We have a fixed php_pdo_mysql.dll in our svn repos - but
the guy that compiled it all hasn't got the source together because it
involved a massive overhaul of the php and extension code to support the
latest mysql libs.
I know your first thoughts will be There's no way I'm going to use a
.dll from a *hackthissite*!, that's fine... but the guy that compiled
it can be trusted, and I've been using it on my windows machine for a
week or two now.
http://source.hackthissite.org/wsvn/HTSv4/trunk/PDO/php_pdo_mysql.dll
I'll see if we can get some sort of source code version together. Until
then, use this at your own risk.
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/39858
--
Edit this bug report at http://bugs.php.net/?id=39858edit=1
#40989 [Fbk-Opn]: PHPinfo output truncated
ID: 40989 User updated by: matt dot parrett at gmail dot com Reported By: matt dot parrett at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: RHEL-latest PHP Version: 5.2.1 New Comment: I've tried all the browsers I have access to. Each seems to break during phpinfo() in it's own unique way. In Firefox 2.0.0.3, the output of phpinfo is truncated when viewing source. The output stops after SCRIPT_FILENAME. There is a closing TD and an opening TD tag following SCRIPT_FILENAME. In Opera 9.10, something similar happens, although in a slightly different spot (immediately after GATEWAY_INTERFACE) --- Regarding the script we developed (that generates about 1000 html rows with 8 columns) seems to go weird somewhere after 6,000 lines of output. When viewing source, I see ??? inserted in a 'random' spot. I also experienced this using wget, but currently cannot seem to reproduce that behavior. Currently, the output just stops -- but only when using a browser. wget retrieves the entire thing just fine. The one time I observed this, the 300kb html file was bloated to 6MB and contained a huge middle section of Could this have something to do with the interplay of the browser and our php distribution or configuration? We use output buffering quite extensively... Thanks. Please let me know if you need anything else. Previous Comments: [2007-04-04 08:17:40] [EMAIL PROTECTED] Use View source to see what exactly you got from the server. Did you try a working browser instead of IE? [2007-04-04 04:07:26] matt dot parrett at gmail dot com Description: php 5.2.1 compiled with: './configure' '--prefix=/usr/local/php-5.2.1' '--with-apxs2=/usr/local/apache2.2/bin/apxs' '--with-mysql' '--with-mysqli' '--with-gd' '--with-pear' '--with-zlib-dir=/usr' '--with-mysql=/opt' '--with-jpeg-dir=/opt' '--with-png-dir=/opt' ?php phpinfo(); ? seems to give truncated output when viewed in a browser. Using wget to retrieve the page gives the expected result. php -i gives proper output. It seems like PHP or our configuration of PHP is doing something wacky with the headers. Not really sure what to look at though. I've configured everything by the book, and have used the same configuration on another server without trouble. Additionally, IE attempts to display the page, then has second thoughts and says 'page cannot be displayed'. We are having similar weird issues with some of our scripts, and found that the simple phpinfo page does the same thing. This is a brand new server with fresh compiles of Apache 2.2 and PHP 5.2.1 - I've tested with PHP 4.4.4 (similar compilation options) and get the same result. Reproduce code: --- ?php phpinfo(); ? Expected result: Full PHPinfo with PHP Variables section at the bottom. Actual result: -- Output ends prior to HTTP Headers Information. -- Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Opn]: PHPinfo output truncated
ID: 40989
User updated by: matt dot parrett at gmail dot com
Reported By: matt dot parrett at gmail dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: RHEL-latest
PHP Version: 5.2.1
New Comment:
Here's another tidbit that may be helpful.
I tried a simple test that works flawlessly on another server that we
have. On the troublemaker, PHP seems to start having trouble at about
16Kb of output. Just like with phpinfo and our main script, this test
works fine as long as you access it using wget or the CLI.
?php
for($i=0;$i1000;$i++) {
echo 'start row:'.$i;
for($j=0;$j9;$j++) {
echo 'cell:'.$j;
}
echo 'end row:'.$i;
}
?
I'd like to rule this out as being a bug. There's a good chance it's
not, but I can't seem to prove it either way.
Previous Comments:
[2007-04-04 15:15:13] matt dot parrett at gmail dot com
I've tried all the browsers I have access to. Each seems to break
during phpinfo() in it's own unique way.
In Firefox 2.0.0.3, the output of phpinfo is truncated when viewing
source. The output stops after SCRIPT_FILENAME. There is a closing TD
and an opening TD tag following SCRIPT_FILENAME.
In Opera 9.10, something similar happens, although in a slightly
different spot (immediately after GATEWAY_INTERFACE)
---
Regarding the script we developed (that generates about 1000 html rows
with 8 columns) seems to go weird somewhere after 6,000 lines of output.
When viewing source, I see ??? inserted
in a 'random' spot. I also experienced this using wget, but currently
cannot seem to reproduce that behavior. Currently, the output just stops
-- but only when using a browser. wget retrieves the entire thing just
fine. The one time I observed this, the 300kb html file was bloated to
6MB and contained a huge middle section of
Could this have something to do with the interplay of the browser and
our php distribution or configuration? We use output buffering quite
extensively...
Thanks. Please let me know if you need anything else.
[2007-04-04 08:17:40] [EMAIL PROTECTED]
Use View source to see what exactly you got from the server.
Did you try a working browser instead of IE?
[2007-04-04 04:07:26] matt dot parrett at gmail dot com
Description:
php 5.2.1 compiled with:
'./configure' '--prefix=/usr/local/php-5.2.1'
'--with-apxs2=/usr/local/apache2.2/bin/apxs' '--with-mysql'
'--with-mysqli' '--with-gd' '--with-pear' '--with-zlib-dir=/usr'
'--with-mysql=/opt' '--with-jpeg-dir=/opt' '--with-png-dir=/opt'
?php phpinfo(); ? seems to give truncated output when viewed in a
browser. Using wget to retrieve the page gives the expected result. php
-i gives proper output.
It seems like PHP or our configuration of PHP is doing something wacky
with the headers. Not really sure what to look at though. I've
configured everything by the book, and have used the same configuration
on another server without trouble.
Additionally, IE attempts to display the page, then has second thoughts
and says 'page cannot be displayed'. We are having similar weird issues
with some of our scripts, and found that the simple phpinfo page does
the same thing.
This is a brand new server with fresh compiles of Apache 2.2 and PHP
5.2.1 - I've tested with PHP 4.4.4 (similar compilation options) and get
the same result.
Reproduce code:
---
?php phpinfo(); ?
Expected result:
Full PHPinfo with PHP Variables section at the bottom.
Actual result:
--
Output ends prior to HTTP Headers Information.
--
Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Fbk-Opn]: PHPinfo output truncated
ID: 40989
User updated by: matt dot parrett at gmail dot com
Reported By: matt dot parrett at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: RHEL-latest
PHP Version: 5.2.1
New Comment:
Make failed. Any suggestions except for trying it without GD?
ext/gd/.libs/gd.o(.text+0x537): In function `zm_shutdown_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1208: undefined
reference to `gdFontCacheMutexShutdown'
ext/gd/.libs/gd.o(.text+0x57a): In function `zm_startup_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1223: undefined
reference to `gdFontCacheMutexSetup'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
Previous Comments:
[2007-04-04 15:38:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Make sure you disabled all zend_extensions and try the snapshot above.
[2007-04-04 15:30:57] matt dot parrett at gmail dot com
Here's another tidbit that may be helpful.
I tried a simple test that works flawlessly on another server that we
have. On the troublemaker, PHP seems to start having trouble at about
16Kb of output. Just like with phpinfo and our main script, this test
works fine as long as you access it using wget or the CLI.
?php
for($i=0;$i1000;$i++) {
echo 'start row:'.$i;
for($j=0;$j9;$j++) {
echo 'cell:'.$j;
}
echo 'end row:'.$i;
}
?
I'd like to rule this out as being a bug. There's a good chance it's
not, but I can't seem to prove it either way.
[2007-04-04 15:15:13] matt dot parrett at gmail dot com
I've tried all the browsers I have access to. Each seems to break
during phpinfo() in it's own unique way.
In Firefox 2.0.0.3, the output of phpinfo is truncated when viewing
source. The output stops after SCRIPT_FILENAME. There is a closing TD
and an opening TD tag following SCRIPT_FILENAME.
In Opera 9.10, something similar happens, although in a slightly
different spot (immediately after GATEWAY_INTERFACE)
---
Regarding the script we developed (that generates about 1000 html rows
with 8 columns) seems to go weird somewhere after 6,000 lines of output.
When viewing source, I see ??? inserted
in a 'random' spot. I also experienced this using wget, but currently
cannot seem to reproduce that behavior. Currently, the output just stops
-- but only when using a browser. wget retrieves the entire thing just
fine. The one time I observed this, the 300kb html file was bloated to
6MB and contained a huge middle section of
Could this have something to do with the interplay of the browser and
our php distribution or configuration? We use output buffering quite
extensively...
Thanks. Please let me know if you need anything else.
[2007-04-04 08:17:40] [EMAIL PROTECTED]
Use View source to see what exactly you got from the server.
Did you try a working browser instead of IE?
[2007-04-04 04:07:26] matt dot parrett at gmail dot com
Description:
php 5.2.1 compiled with:
'./configure' '--prefix=/usr/local/php-5.2.1'
'--with-apxs2=/usr/local/apache2.2/bin/apxs' '--with-mysql'
'--with-mysqli' '--with-gd' '--with-pear' '--with-zlib-dir=/usr'
'--with-mysql=/opt' '--with-jpeg-dir=/opt' '--with-png-dir=/opt'
?php phpinfo(); ? seems to give truncated output when viewed in a
browser. Using wget to retrieve the page gives the expected result. php
-i gives proper output.
It seems like PHP or our configuration of PHP is doing something wacky
with the headers. Not really sure what to look at though. I've
configured everything by the book, and have used the same configuration
on another server without trouble.
Additionally, IE attempts to display the page, then has second thoughts
and says 'page cannot be displayed'. We are having similar weird issues
with some of our scripts, and found that the simple phpinfo page does
the same thing.
This is a brand new server with fresh compiles of Apache 2.2 and PHP
5.2.1 - I've tested with PHP 4.4.4 (similar compilation options) and get
the same result.
Reproduce code:
---
?php phpinfo(); ?
Expected result:
Full PHPinfo with PHP Variables section at the bottom.
Actual result:
--
Output ends prior to HTTP Headers Information.
--
Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Opn]: PHPinfo output truncated
ID: 40989 User updated by: matt dot parrett at gmail dot com Reported By: matt dot parrett at gmail dot com Status: Open Bug Type: Unknown/Other Function Operating System: RHEL-latest PHP Version: 5.2.1 New Comment: The only thing I changed was the prefix. /usr/local/php5-snapshot In any case, GD is not required to reproduce the behavior. Previous Comments: [2007-04-04 16:45:30] matt dot parrett at gmail dot com I compiled without GD, and tested the latest snapshot as you requested. I'm experiencing the same behavior as I described before. I used the configure line I pasted in the original bug report. [2007-04-04 16:38:32] [EMAIL PROTECTED] I've just compiled the same extension without problem, what's the exact configure line that you used? [2007-04-04 16:10:44] [EMAIL PROTECTED] Is GD required to reproduce it? [2007-04-04 16:05:44] matt dot parrett at gmail dot com Make failed. Any suggestions except for trying it without GD? ext/gd/.libs/gd.o(.text+0x537): In function `zm_shutdown_gd': /usr/local/src/php5.2-200704041430/ext/gd/gd.c:1208: undefined reference to `gdFontCacheMutexShutdown' ext/gd/.libs/gd.o(.text+0x57a): In function `zm_startup_gd': /usr/local/src/php5.2-200704041430/ext/gd/gd.c:1223: undefined reference to `gdFontCacheMutexSetup' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 [2007-04-04 15:38:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Make sure you disabled all zend_extensions and try the snapshot above. 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/40989 -- Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Fbk-Opn]: PHPinfo output truncated
ID: 40989 User updated by: matt dot parrett at gmail dot com Reported By: matt dot parrett at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: RHEL-latest PHP Version: 5.2.1 New Comment: Is there some interplay between apache and PHP that might be required to reproduce this? For apache, we used 2.2.4 sources with ./configure --prefix=/usr/local/apache-2.2.4 -without-suexec-userdir -with-mpm=prefork --enable-so --enable-rewrite Previous Comments: [2007-04-04 18:03:30] [EMAIL PROTECTED] I'm still unable to replicate it. [2007-04-04 16:47:57] matt dot parrett at gmail dot com The only thing I changed was the prefix. /usr/local/php5-snapshot In any case, GD is not required to reproduce the behavior. [2007-04-04 16:45:30] matt dot parrett at gmail dot com I compiled without GD, and tested the latest snapshot as you requested. I'm experiencing the same behavior as I described before. I used the configure line I pasted in the original bug report. [2007-04-04 16:38:32] [EMAIL PROTECTED] I've just compiled the same extension without problem, what's the exact configure line that you used? [2007-04-04 16:10:44] [EMAIL PROTECTED] Is GD required to reproduce it? 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/40989 -- Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Fbk-Opn]: PHPinfo output truncated
ID: 40989 User updated by: matt dot parrett at gmail dot com Reported By: matt dot parrett at gmail dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: RHEL-latest PHP Version: 5.2.1 New Comment: Tony, I sent you an email with info on how to access the misbehaving page, since this is a project for an internal admin page. Previous Comments: [2007-04-04 18:20:13] [EMAIL PROTECTED] Is the data received by the browser correct? Are there any firewalls or filters between the server and the browser? Where can I see the problem? (is there a public http server?) [2007-04-04 18:14:06] matt dot parrett at gmail dot com Is there some interplay between apache and PHP that might be required to reproduce this? For apache, we used 2.2.4 sources with ./configure --prefix=/usr/local/apache-2.2.4 -without-suexec-userdir -with-mpm=prefork --enable-so --enable-rewrite [2007-04-04 18:03:30] [EMAIL PROTECTED] I'm still unable to replicate it. [2007-04-04 16:47:57] matt dot parrett at gmail dot com The only thing I changed was the prefix. /usr/local/php5-snapshot In any case, GD is not required to reproduce the behavior. [2007-04-04 16:45:30] matt dot parrett at gmail dot com I compiled without GD, and tested the latest snapshot as you requested. I'm experiencing the same behavior as I described before. I used the configure line I pasted in the original bug 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/40989 -- Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Fbk-Csd]: PHPinfo output truncated
ID: 40989 User updated by: matt dot parrett at gmail dot com Reported By: matt dot parrett at gmail dot com -Status: Feedback +Status: Closed Bug Type: Unknown/Other Function Operating System: RHEL-latest PHP Version: 5.2.1 New Comment: We have a rack with a hardware firewall, and have iptables on most servers. I don't see anything different on this server. Our other servers seem to have no trouble with PHP. It seems pretty likely that this isn't a PHP bug, so I will stop expending your resources. Thank you for your time. Previous Comments: [2007-04-04 20:04:04] [EMAIL PROTECTED] If you look at the source of the page, you'd see lots of null bytes. Make sure you don't have any firewalls (including hardware ones) or anything else that might affect the output. And try to rebuild Apache using minimal configuration. Doesn't seem to be PHP problem, PHP doesn't insert 600K of null bytes in phpinfo(). [2007-04-04 19:02:02] matt dot parrett at gmail dot com Tony, I sent you an email with info on how to access the misbehaving page, since this is a project for an internal admin page. [2007-04-04 18:20:13] [EMAIL PROTECTED] Is the data received by the browser correct? Are there any firewalls or filters between the server and the browser? Where can I see the problem? (is there a public http server?) [2007-04-04 18:14:06] matt dot parrett at gmail dot com Is there some interplay between apache and PHP that might be required to reproduce this? For apache, we used 2.2.4 sources with ./configure --prefix=/usr/local/apache-2.2.4 -without-suexec-userdir -with-mpm=prefork --enable-so --enable-rewrite [2007-04-04 18:03:30] [EMAIL PROTECTED] I'm still unable to replicate it. 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/40989 -- Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [Fbk-Opn]: PHPinfo output truncated
ID: 40989
User updated by: matt dot parrett at gmail dot com
Reported By: matt dot parrett at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: RHEL-latest
PHP Version: 5.2.1
New Comment:
I compiled without GD, and tested the latest snapshot as you requested.
I'm experiencing the same behavior as I described before.
I used the configure line I pasted in the original bug report.
Previous Comments:
[2007-04-04 16:38:32] [EMAIL PROTECTED]
I've just compiled the same extension without problem, what's the exact
configure line that you used?
[2007-04-04 16:10:44] [EMAIL PROTECTED]
Is GD required to reproduce it?
[2007-04-04 16:05:44] matt dot parrett at gmail dot com
Make failed. Any suggestions except for trying it without GD?
ext/gd/.libs/gd.o(.text+0x537): In function `zm_shutdown_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1208: undefined
reference to `gdFontCacheMutexShutdown'
ext/gd/.libs/gd.o(.text+0x57a): In function `zm_startup_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1223: undefined
reference to `gdFontCacheMutexSetup'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
[2007-04-04 15:38:46] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
Make sure you disabled all zend_extensions and try the snapshot above.
[2007-04-04 15:30:57] matt dot parrett at gmail dot com
Here's another tidbit that may be helpful.
I tried a simple test that works flawlessly on another server that we
have. On the troublemaker, PHP seems to start having trouble at about
16Kb of output. Just like with phpinfo and our main script, this test
works fine as long as you access it using wget or the CLI.
?php
for($i=0;$i1000;$i++) {
echo 'start row:'.$i;
for($j=0;$j9;$j++) {
echo 'cell:'.$j;
}
echo 'end row:'.$i;
}
?
I'd like to rule this out as being a bug. There's a good chance it's
not, but I can't seem to prove it either way.
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/40989
--
Edit this bug report at http://bugs.php.net/?id=40989edit=1
#40989 [NEW]: PHPinfo output truncated
From: matt dot parrett at gmail dot com Operating system: RHEL-latest PHP version: 5.2.1 PHP Bug Type: Unknown/Other Function Bug description: PHPinfo output truncated Description: php 5.2.1 compiled with: './configure' '--prefix=/usr/local/php-5.2.1' '--with-apxs2=/usr/local/apache2.2/bin/apxs' '--with-mysql' '--with-mysqli' '--with-gd' '--with-pear' '--with-zlib-dir=/usr' '--with-mysql=/opt' '--with-jpeg-dir=/opt' '--with-png-dir=/opt' ?php phpinfo(); ? seems to give truncated output when viewed in a browser. Using wget to retrieve the page gives the expected result. php -i gives proper output. It seems like PHP or our configuration of PHP is doing something wacky with the headers. Not really sure what to look at though. I've configured everything by the book, and have used the same configuration on another server without trouble. Additionally, IE attempts to display the page, then has second thoughts and says 'page cannot be displayed'. We are having similar weird issues with some of our scripts, and found that the simple phpinfo page does the same thing. This is a brand new server with fresh compiles of Apache 2.2 and PHP 5.2.1 - I've tested with PHP 4.4.4 (similar compilation options) and get the same result. Reproduce code: --- ?php phpinfo(); ? Expected result: Full PHPinfo with PHP Variables section at the bottom. Actual result: -- Output ends prior to HTTP Headers Information. -- Edit bug report at http://bugs.php.net/?id=40989edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40989r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40989r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40989r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40989r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40989r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40989r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40989r=needscript Try newer version:http://bugs.php.net/fix.php?id=40989r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40989r=support Expected behavior:http://bugs.php.net/fix.php?id=40989r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40989r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40989r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40989r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40989r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40989r=dst IIS Stability:http://bugs.php.net/fix.php?id=40989r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40989r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40989r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40989r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40989r=mysqlcfg
#38805 [Com]: PDO Truncates Text from SQL Server Text Data Type Field
ID: 38805 Comment by: matt at educause dot edu Reported By: gkrajci at arescorporation dot com Status: Assigned Bug Type: PDO related Operating System: Windows NT PBMA-WB2 5.2 build 37 PHP Version: 5.1.6 Assigned To: wez New Comment: I too can reproduce this problem ... a critical hurdle for us. Previous Comments: [2006-12-06 14:50:17] frank at interlevel dot com Seems I am not alone on this. I have also tried altering the PHP.ini with no result. IS there an update to this PDO? [2006-11-08 14:30:06] mark dot pearson at capita dot co dot uk I have found the same problem with PHP 5.1.6 running on Windows XP Pro SP2 and MS SQL Server 2000 (using the pdo_mssql driver). I also tried to solve it by setting the mssql.textlimit and mssql.textsize INI options, since that used to cause the same problem in the mssql extension but it doesn't have any effect on the values returned by PDO. [2006-09-26 16:22:57] ritch at bugsoftware dot co dot uk I'm also suffering this problem after changing my database connection type to PDO. I'm running PHP 5.1.2 on Windows server 2003 with MSSQL 2005. In the old mssql ext. you had to specificaly tell the configure it in php.ini to bring back larger text fields: ; Valid range 0 - 2147483647. Default = 4096. mssql.textlimit = 2147483647 ; Valid range 0 - 2147483647. Default = 4096. mssql.textsize = 2147483647 I have not found the same for the new PDO extension - so I'm assuming this has some thing to do with the problem. (My text fields are also truncated to 4096) Help with this issue would be greatley appreciated. [2006-09-14 11:47:26] gkrajci at arescorporation dot com Microsoft SQL Server connections PHP.INI --- extension=php_pdo.dll extension=php_pdo_mssql.dll extension=php_pdo_mysql.dll PDO PDO support enabled PDO drivers mssql, mysql pdo_mssql PDO Driver for MSSQL DB-lib enabled Flavour MSSQL_70 pdo_mysql PDO Driver for MySQL, client library version 5.0.22 [2006-09-13 15:45:31] [EMAIL PROTECTED] I assume you're using ODBC? 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/38805 -- Edit this bug report at http://bugs.php.net/?id=38805edit=1
#40003 [Bgs]: strtotime(), incorrect results
ID: 40003
User updated by: matt at iws dot co dot nz
Reported By: matt at iws dot co dot nz
Status: Bogus
Bug Type: Date/time related
Operating System: Linux 2.4
PHP Version: 5.2.0
New Comment:
Shouldn't Second Monday Jan 2007 and Second Tuesday Jan 2007 return
days consecutive days in Jan 2007, instead of dates one week apart?
Second Monday Feb 2007 and Second Tuesday Feb 2007 return the
correct results. As far as I can tell the results are always
inconsistent for the weekday that is the first day of the month.
Example Code:
-
echo date('Y-m-d', strtotime('second monday jan 2007')); // returns
2007-01-15
echo date('Y-m-d', strtotime('second tuesday jan 2007')); // returns
2007-01-09
Previous Comments:
[2007-01-03 08:08:41] [EMAIL PROTECTED]
This is not a bug, but expected behaviour. To get the behaviour that
you want, simply use Monday Jan 2007 (without the first).
[2007-01-02 23:15:33] matt at iws dot co dot nz
Description:
Asking strtotime() for the date of the first occurrence of a particular
day of the week, when that day of the week is also the first day of the
month, returns the incorrect day. See examples below.
Reproduce code:
---
echo date('Y-m-d', strtotime('first monday jan 2007'));
echo date('Y-m-d', strtotime('first monday feb 2007'));
echo date('Y-m-d', strtotime('first thursday feb 2007'));
echo date('Y-m-d', strtotime('first thursday jan 2007'));
Expected result:
// First Monday Jan 2007
2007-01-01
// First Monday Feb 2007
2007-02-05
// First Thursday Feb 2007
2007-02-01
// First Thursday Jan 2007
2007-01-04
Actual result:
--
// First Monday Jan 2007 - incorrect
2007-01-08
// First Monday Feb 2007 - correct
2007-02-05
// First Thursday Feb 2007 - incorrect
2007-02-08
// First Thursday Jan 2007 - correct
2007-01-04
--
Edit this bug report at http://bugs.php.net/?id=40003edit=1
#40003 [NEW]: strtotime(), incorrect results
From: matt at iws dot co dot nz
Operating system: Linux 2.4
PHP version: 5.2.0
PHP Bug Type: Date/time related
Bug description: strtotime(), incorrect results
Description:
Asking strtotime() for the date of the first occurrence of a particular
day of the week, when that day of the week is also the first day of the
month, returns the incorrect day. See examples below.
Reproduce code:
---
echo date('Y-m-d', strtotime('first monday jan 2007'));
echo date('Y-m-d', strtotime('first monday feb 2007'));
echo date('Y-m-d', strtotime('first thursday feb 2007'));
echo date('Y-m-d', strtotime('first thursday jan 2007'));
Expected result:
// First Monday Jan 2007
2007-01-01
// First Monday Feb 2007
2007-02-05
// First Thursday Feb 2007
2007-02-01
// First Thursday Jan 2007
2007-01-04
Actual result:
--
// First Monday Jan 2007 - incorrect
2007-01-08
// First Monday Feb 2007 - correct
2007-02-05
// First Thursday Feb 2007 - incorrect
2007-02-08
// First Thursday Jan 2007 - correct
2007-01-04
--
Edit bug report at http://bugs.php.net/?id=40003edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=40003r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=40003r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=40003r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40003r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=40003r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=40003r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40003r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40003r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=40003r=support
Expected behavior:http://bugs.php.net/fix.php?id=40003r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=40003r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=40003r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40003r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40003r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40003r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40003r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=40003r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=40003r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=40003r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40003r=mysqlcfg
#39752 [NEW]: Can't start Apache2 due to libphp5.so error.
From: matt dot selph at gmail dot com Operating system: Suse 9.3 PHP version: 5.2.0 PHP Bug Type: Apache2 related Bug description: Can't start Apache2 due to libphp5.so error. Description: Cannot start Apache 2.2.3 after I compiled and installed php 5.2.0. I get an error regarding libphp5.so and an undefined sqlite3 symbol. Reproduce code: --- Apache 2.2.3 configuration: ./configure --enable-so PHP 5.2.0 configuration: ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-gettext --with-xml --with-zlib-dir=/usr/local/php-5.2.0/ext/zlib --with-jpeg-dir Error message: ./apachectl -k start httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3ExprDelete Expected result: Expected Apache to start with no errors. Actual result: -- Got the following error: ./apachectl -k start httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3ExprDelete Also a ps -ef | grep httpd showed no web server daemons running. -- Edit bug report at http://bugs.php.net/?id=39752edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39752r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39752r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39752r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39752r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39752r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39752r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39752r=needscript Try newer version:http://bugs.php.net/fix.php?id=39752r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39752r=support Expected behavior:http://bugs.php.net/fix.php?id=39752r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39752r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39752r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39752r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39752r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39752r=dst IIS Stability:http://bugs.php.net/fix.php?id=39752r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39752r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39752r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39752r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39752r=mysqlcfg
#39752 [Fbk-Csd]: Can't start Apache2 due to libphp5.so error.
ID: 39752 User updated by: matt dot selph at gmail dot com Reported By: matt dot selph at gmail dot com -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Suse 9.3 PHP Version: 5.2.0 New Comment: make clean worked. thanks for your prompt reply. Previous Comments: [2006-12-06 13:25:16] [EMAIL PROTECTED] make clean? [2006-12-06 13:19:58] matt dot selph at gmail dot com Description: Cannot start Apache 2.2.3 after I compiled and installed php 5.2.0. I get an error regarding libphp5.so and an undefined sqlite3 symbol. Reproduce code: --- Apache 2.2.3 configuration: ./configure --enable-so PHP 5.2.0 configuration: ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/local/apache2/bin/apxs --enable-xml --with-gd --with-gettext --with-xml --with-zlib-dir=/usr/local/php-5.2.0/ext/zlib --with-jpeg-dir Error message: ./apachectl -k start httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3ExprDelete Expected result: Expected Apache to start with no errors. Actual result: -- Got the following error: ./apachectl -k start httpd: Syntax error on line 53 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/libphp5.so into server: /usr/local/apache2/modules/libphp5.so: undefined symbol: sqlite3ExprDelete Also a ps -ef | grep httpd showed no web server daemons running. -- Edit this bug report at http://bugs.php.net/?id=39752edit=1
#39278 [NEW]: strpos($needle, $integer) returns 0 for certain values of $integer
From: matt at raines dot me dot uk Operating system: GNU/Linux 2.4.27 PHP version: 5.1.6 PHP Bug Type: Strings related Bug description: strpos($needle, $integer) returns 0 for certain values of $integer Description: Searching for a string in an integer using strpos() returns integer 0 if (integer % 256) is the lowest ASCII value of any character in the search string, or the highest ASCII value of any character minus 256. Otherwise it returns boolean false as expected. Reproduce code: --- var_dump(strpos(A, 65)); var_dump(strpos(A, 66)); var_dump(strpos(B, 65)); var_dump(strpos(B, 66)); Expected result: bool(false) bool(false) bool(false) bool(false) Actual result: -- int(0) bool(false) bool(false) int(0) -- Edit bug report at http://bugs.php.net/?id=39278edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39278r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39278r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39278r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39278r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39278r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39278r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39278r=needscript Try newer version:http://bugs.php.net/fix.php?id=39278r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39278r=support Expected behavior:http://bugs.php.net/fix.php?id=39278r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39278r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39278r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39278r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39278r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39278r=dst IIS Stability:http://bugs.php.net/fix.php?id=39278r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39278r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39278r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39278r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39278r=mysqlcfg
#39233 [Csd-Opn]: Windows MSI installer cannot configure Apache 2.2
ID: 39233
User updated by: matt at genesi-usa dot com
Reported By: matt at genesi-usa dot com
-Status: Closed
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows XP Home SP2
PHP Version: 5.2.0RC5
Assigned To: jmertic
New Comment:
the (!copy(httpd.conf, httpd.conf.bak)) check still fails here for some
reason (permission denied?)
Previous Comments:
[2006-10-24 12:10:20] [EMAIL PROTECTED]
Added removal of ';' in $foldername, and tweaked check for file ( using
is_file() instead of file() ) now in CVS.
[2006-10-23 09:49:38] matt at genesi-usa dot com
Description:
The apacheconfig.php script bundled with the new MSI installer breaks;
when selecting a directory from the installer, a semicolon is appended
to the path. When it is passed to the script, the script builds
configuration filenames as:
C:\Program Files\Apache Software Foundation\Apache2.2\conf\;httpd.conf
Fixing that error, it fails to backup the httpd.conf and mime.types
files before editing.
Reproduce code:
---
Select Apache 2.2 module from the list, pick a directory.
I fixed it by changing:
$foldername = str_replace(array('', ';\\'), array('','\\'),
$argv[2]);
Also even though I run as Administrator for the purposes of installing,
the two backup checks fail for some reason. I didn't look into this so I
just commented that entire elseif statement out for both files (I don't
need a backup it was a fresh Apache 2.2 install with the default
configuration file)
--
Edit this bug report at http://bugs.php.net/?id=39233edit=1
#39233 [NEW]: Windows MSI installer cannot configure Apache 2.2
From: matt at genesi-usa dot com
Operating system: Windows XP Home SP2
PHP version: 5.2.0RC5
PHP Bug Type: Unknown/Other Function
Bug description: Windows MSI installer cannot configure Apache 2.2
Description:
The apacheconfig.php script bundled with the new MSI installer breaks;
when selecting a directory from the installer, a semicolon is appended to
the path. When it is passed to the script, the script builds configuration
filenames as:
C:\Program Files\Apache Software Foundation\Apache2.2\conf\;httpd.conf
Fixing that error, it fails to backup the httpd.conf and mime.types files
before editing.
Reproduce code:
---
Select Apache 2.2 module from the list, pick a directory.
I fixed it by changing:
$foldername = str_replace(array('', ';\\'), array('','\\'), $argv[2]);
Also even though I run as Administrator for the purposes of installing,
the two backup checks fail for some reason. I didn't look into this so I
just commented that entire elseif statement out for both files (I don't
need a backup it was a fresh Apache 2.2 install with the default
configuration file)
--
Edit bug report at http://bugs.php.net/?id=39233edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39233r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39233r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39233r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39233r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39233r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39233r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39233r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39233r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39233r=support
Expected behavior:http://bugs.php.net/fix.php?id=39233r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39233r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39233r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39233r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39233r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39233r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39233r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39233r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39233r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39233r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39233r=mysqlcfg
#37952 [NEW]: MySQL Extension not working with php5apache2.dll
From: matt at criticalcode dot com Operating system: Windows XP Build 2600 PHP version: 5CVS-2006-06-28 (snap) PHP Bug Type: Apache2 related Bug description: MySQL Extension not working with php5apache2.dll Description: Install Apache 2.0.58 Unpack and put php5.2.0-dev snap into c:/php Follow install instructions on php.net/install Using php5apache2.dll, I can see the php.ini path in Apache is c:\WINDOWS, I rename php.ini-recommended, restart apache2, server will not process php files. Use php.ini-dist, PHP as CGI (see install guide), everythign works fine. So basically, you cannot use MySQL and php5apache2.dll together. I tested all the variances of thise setup. But I'm keeping it short here. Also tested on Apache 2.0.55 - same results -- Edit bug report at http://bugs.php.net/?id=37952edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37952r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37952r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37952r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37952r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37952r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37952r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37952r=needscript Try newer version:http://bugs.php.net/fix.php?id=37952r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37952r=support Expected behavior:http://bugs.php.net/fix.php?id=37952r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37952r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37952r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37952r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37952r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37952r=dst IIS Stability:http://bugs.php.net/fix.php?id=37952r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37952r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37952r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37952r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37952r=mysqlcfg
#37952 [Bgs]: MySQL Extension not working with php5apache2.dll
ID: 37952 User updated by: matt at criticalcode dot com Reported By: matt at criticalcode dot com Status: Bogus Bug Type: Apache2 related Operating System: Windows XP Build 2600 PHP Version: 5CVS-2006-06-28 (snap) New Comment: Yes, I did read about this. I added c:/php to my windows PATH= environmental variables and rebooted. This had no effect on MySQL. Also the extension php_mysql.dll was enabled in the c:/php/php.ini Previous Comments: [2006-06-28 22:02:46] [EMAIL PROTECTED] http://php.net/mysql MySQL is no longer enabled by default, so the php_mysql.dll DLL must be enabled inside of php.ini. Also, PHP needs access to the MySQL client library. A file named libmysql.dll is included in the Windows PHP distribution and in order for PHP to talk to MySQL this file needs to be available to the Windows systems PATH. See the FAQ titled How do I add my PHP directory to the PATH on Windows for information on how to do this. Although copying libmysql.dll to the Windows system directory also works (because the system directory is by default in the system's PATH), it's not recommended. [2006-06-28 21:25:35] matt at criticalcode dot com Description: Install Apache 2.0.58 Unpack and put php5.2.0-dev snap into c:/php Follow install instructions on php.net/install Using php5apache2.dll, I can see the php.ini path in Apache is c:\WINDOWS, I rename php.ini-recommended, restart apache2, server will not process php files. Use php.ini-dist, PHP as CGI (see install guide), everythign works fine. So basically, you cannot use MySQL and php5apache2.dll together. I tested all the variances of thise setup. But I'm keeping it short here. Also tested on Apache 2.0.55 - same results -- Edit this bug report at http://bugs.php.net/?id=37952edit=1
#37723 [Bgs-Opn]: Incorrect Inheretence Context
ID: 37723 User updated by: matt at c dot anvas dot es Reported By: matt at c dot anvas dot es -Status: Bogus +Status: Open Bug Type: Class/Object related Operating System: Any PHP Version: 5.1.4 New Comment: See previous comment Previous Comments: [2006-06-07 22:32:55] matt at c dot anvas dot es The fact that it ignores the child class if it doesn't define a matching static method and instead changes its context to that of the parent is expected? How does that make sense if it inherits the parent class? If it does, indeed, inherit the parent class, it will have the static method, not having to go to the parent and ignore the child's existence. I understand that finding methods and the like from parents can be tricky, having to navigate the inheritence tree, but it's unexpected to suddenly become the parent class when you're working with the child class. I may not sway you to keep this open as an actual bug (as I see it), but your answers will at least teach me, if nothing else, the mindset of the core developers et al. I'd like to know if late static binding is considered a feature or a bug fix. If it is a bug fix, then you're right: this bug report is just a duplicate. However, if the late static binding really is just a feature to cover this up, I see a potential problem. I'd like to know, really, if this is considered a bug or a mere inconvenience. M.T. [2006-06-07 22:02:21] [EMAIL PROTECTED] hey, this is a bug, because the child class should inheret its parents innards' That's EXACTLY what it does and I personally consider this expected. The child inherits parents context, what's wrong here? But we're working on late static binding, which would change this behaviour to the expected one, that's why there is no sense in keeping this report open. Thank you. [2006-06-07 21:02:04] matt at c dot anvas dot es I did search, and I see something beyond 'late static binding' here. The child class (or the parser) is leaving its context in search of the method to inheret, but it doesn't bring it into its context. In fact, it takes the user into the parent's context. It changes its context. This goes beyond simply saying that you're trying to figure out how to do 'late static binding', and more into the realm of 'hey, this is a bug, because the child class should inheret its parents innards, and _stay within its context_.' Am I mistaken in this thought? Is is perfectly OK and not a bug that the context itself is changed? I submitted this bug because I don't think the previous bug submissions adequately described the issue at hand. Please read the description. M.T. [2006-06-07 08:05:47] [EMAIL PROTECTED] Try to search bug DB before reporting new issues. See bug #37654 and bug #37684. [2006-06-07 08:04:39] matt at c dot anvas dot es (Fixed name) 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/37723 -- Edit this bug report at http://bugs.php.net/?id=37723edit=1
#37723 [NEW]: Incorrect Inheretence Context
From: matt at c dot anvas dot es
Operating system: Any
PHP version: 5.1.4
PHP Bug Type: Class/Object related
Bug description: Incorrect Inheretence Context
Description:
Though I've verified that others have noted the same problem
with code similar to mine, I noticed what appeared to be a
greater problem than at first realized.
In the code below, a call to get_class() from a static
method inhereted from the parent class actually shows no
evidence of inheretence. One look at the stacktrace and
you'll not even see one mention of the child class.
Late static binding may fix this, as I'm not precisely sure
what that does and what the exact problem is, but the way I
see it, the child class is not inhereting everything from
its parent but has, instead, thrown the call to its parent,
thereby changing its context.
Again, consider the code: my context is that I'm talking
with a child object, whose parent has a static method that
gets its name. Unfortunately, when asking the child its
name, the parent's name is instead given. If indeed the
child has inhereted its parents properties and methods, then
this is a bug whereby it changes the context outside of
itself.
Compare this to human inheretence and the children inheret
all of the properties from their parents (though a bit
organically with crossing over and the like). But still, it
contains those things and does not go to the parent every
time a property or an action needs to be consulted or acted.
Again, a look at the backtrace reveals that it totally skips
the child class, as if it doesn't even exist.
Reproduce code:
---
class Parent {
public static function name() {
// debug_print_backtrace(); // observe this
return get_class();
}
}
class Child extends Parent {}
print Child::name();
Expected result:
Child
Actual result:
--
Parent
--
Edit bug report at http://bugs.php.net/?id=37723edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37723r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37723r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37723r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37723r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37723r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37723r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37723r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37723r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37723r=support
Expected behavior:http://bugs.php.net/fix.php?id=37723r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37723r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37723r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37723r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37723r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37723r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37723r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37723r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37723r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37723r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37723r=mysqlcfg
#37723 [Opn]: Incorrect Context Inheritence
ID: 37723
User updated by: matt at c dot anvas dot es
-Summary: Incorrect Inheretence Context
Reported By: matt at c dot anvas dot es
Status: Open
Bug Type: Class/Object related
Operating System: Any
PHP Version: 5.1.4
New Comment:
(Fixed name)
Previous Comments:
[2006-06-07 07:34:51] matt at c dot anvas dot es
Description:
Though I've verified that others have noted the same problem
with code similar to mine, I noticed what appeared to be a
greater problem than at first realized.
In the code below, a call to get_class() from a static
method inhereted from the parent class actually shows no
evidence of inheretence. One look at the stacktrace and
you'll not even see one mention of the child class.
Late static binding may fix this, as I'm not precisely sure
what that does and what the exact problem is, but the way I
see it, the child class is not inhereting everything from
its parent but has, instead, thrown the call to its parent,
thereby changing its context.
Again, consider the code: my context is that I'm talking
with a child object, whose parent has a static method that
gets its name. Unfortunately, when asking the child its
name, the parent's name is instead given. If indeed the
child has inhereted its parents properties and methods, then
this is a bug whereby it changes the context outside of
itself.
Compare this to human inheretence and the children inheret
all of the properties from their parents (though a bit
organically with crossing over and the like). But still, it
contains those things and does not go to the parent every
time a property or an action needs to be consulted or acted.
Again, a look at the backtrace reveals that it totally skips
the child class, as if it doesn't even exist.
Reproduce code:
---
class Parent {
public static function name() {
// debug_print_backtrace(); // observe this
return get_class();
}
}
class Child extends Parent {}
print Child::name();
Expected result:
Child
Actual result:
--
Parent
--
Edit this bug report at http://bugs.php.net/?id=37723edit=1
#37723 [Bgs-Opn]: Incorrect Inheretence Context
ID: 37723
User updated by: matt at c dot anvas dot es
Reported By: matt at c dot anvas dot es
-Status: Bogus
+Status: Open
Bug Type: Class/Object related
Operating System: Any
PHP Version: 5.1.4
New Comment:
I did search, and I see something beyond 'late static
binding' here. The child class (or the parser) is leaving
its context in search of the method to inheret, but it
doesn't bring it into its context. In fact, it takes the
user into the parent's context. It changes its context.
This goes beyond simply saying that you're trying to figure
out how to do 'late static binding', and more into the realm
of 'hey, this is a bug, because the child class should
inheret its parents innards, and _stay within its context_.'
Am I mistaken in this thought? Is is perfectly OK and not a
bug that the context itself is changed?
I submitted this bug because I don't think the previous bug
submissions adequately described the issue at hand. Please
read the description.
M.T.
Previous Comments:
[2006-06-07 08:05:47] [EMAIL PROTECTED]
Try to search bug DB before reporting new issues.
See bug #37654 and bug #37684.
[2006-06-07 08:04:39] matt at c dot anvas dot es
(Fixed name)
[2006-06-07 07:34:51] matt at c dot anvas dot es
Description:
Though I've verified that others have noted the same problem
with code similar to mine, I noticed what appeared to be a
greater problem than at first realized.
In the code below, a call to get_class() from a static
method inhereted from the parent class actually shows no
evidence of inheretence. One look at the stacktrace and
you'll not even see one mention of the child class.
Late static binding may fix this, as I'm not precisely sure
what that does and what the exact problem is, but the way I
see it, the child class is not inhereting everything from
its parent but has, instead, thrown the call to its parent,
thereby changing its context.
Again, consider the code: my context is that I'm talking
with a child object, whose parent has a static method that
gets its name. Unfortunately, when asking the child its
name, the parent's name is instead given. If indeed the
child has inhereted its parents properties and methods, then
this is a bug whereby it changes the context outside of
itself.
Compare this to human inheretence and the children inheret
all of the properties from their parents (though a bit
organically with crossing over and the like). But still, it
contains those things and does not go to the parent every
time a property or an action needs to be consulted or acted.
Again, a look at the backtrace reveals that it totally skips
the child class, as if it doesn't even exist.
Reproduce code:
---
class Parent {
public static function name() {
// debug_print_backtrace(); // observe this
return get_class();
}
}
class Child extends Parent {}
print Child::name();
Expected result:
Child
Actual result:
--
Parent
--
Edit this bug report at http://bugs.php.net/?id=37723edit=1
#37723 [Bgs]: Incorrect Inheretence Context
ID: 37723
User updated by: matt at c dot anvas dot es
Reported By: matt at c dot anvas dot es
Status: Bogus
Bug Type: Class/Object related
Operating System: Any
PHP Version: 5.1.4
New Comment:
The fact that it ignores the child class if it doesn't
define a matching static method and instead changes its
context to that of the parent is expected? How does that
make sense if it inherits the parent class? If it does,
indeed, inherit the parent class, it will have the static
method, not having to go to the parent and ignore the
child's existence.
I understand that finding methods and the like from parents
can be tricky, having to navigate the inheritence tree, but
it's unexpected to suddenly become the parent class when
you're working with the child class.
I may not sway you to keep this open as an actual bug (as I
see it), but your answers will at least teach me, if nothing
else, the mindset of the core developers et al.
I'd like to know if late static binding is considered a
feature or a bug fix. If it is a bug fix, then you're right:
this bug report is just a duplicate. However, if the late
static binding really is just a feature to cover this up, I
see a potential problem. I'd like to know, really, if this
is considered a bug or a mere inconvenience.
M.T.
Previous Comments:
[2006-06-07 22:02:21] [EMAIL PROTECTED]
hey, this is a bug, because the child class should
inheret its parents innards'
That's EXACTLY what it does and I personally consider this expected.
The child inherits parents context, what's wrong here?
But we're working on late static binding, which would change this
behaviour to the expected one, that's why there is no sense in keeping
this report open.
Thank you.
[2006-06-07 21:02:04] matt at c dot anvas dot es
I did search, and I see something beyond 'late static
binding' here. The child class (or the parser) is leaving
its context in search of the method to inheret, but it
doesn't bring it into its context. In fact, it takes the
user into the parent's context. It changes its context.
This goes beyond simply saying that you're trying to figure
out how to do 'late static binding', and more into the realm
of 'hey, this is a bug, because the child class should
inheret its parents innards, and _stay within its context_.'
Am I mistaken in this thought? Is is perfectly OK and not a
bug that the context itself is changed?
I submitted this bug because I don't think the previous bug
submissions adequately described the issue at hand. Please
read the description.
M.T.
[2006-06-07 08:05:47] [EMAIL PROTECTED]
Try to search bug DB before reporting new issues.
See bug #37654 and bug #37684.
[2006-06-07 08:04:39] matt at c dot anvas dot es
(Fixed name)
[2006-06-07 07:34:51] matt at c dot anvas dot es
Description:
Though I've verified that others have noted the same problem
with code similar to mine, I noticed what appeared to be a
greater problem than at first realized.
In the code below, a call to get_class() from a static
method inhereted from the parent class actually shows no
evidence of inheretence. One look at the stacktrace and
you'll not even see one mention of the child class.
Late static binding may fix this, as I'm not precisely sure
what that does and what the exact problem is, but the way I
see it, the child class is not inhereting everything from
its parent but has, instead, thrown the call to its parent,
thereby changing its context.
Again, consider the code: my context is that I'm talking
with a child object, whose parent has a static method that
gets its name. Unfortunately, when asking the child its
name, the parent's name is instead given. If indeed the
child has inhereted its parents properties and methods, then
this is a bug whereby it changes the context outside of
itself.
Compare this to human inheretence and the children inheret
all of the properties from their parents (though a bit
organically with crossing over and the like). But still, it
contains those things and does not go to the parent every
time a property or an action needs to be consulted or acted.
Again, a look at the backtrace reveals that it totally skips
the child class, as if it doesn't even exist.
Reproduce code:
---
class Parent {
public static function name() {
// debug_print_backtrace(); // observe this
return get_class();
}
}
class Child extends Parent {}
print Child::name();
Expected result:
Child
Actual result:
--
Parent
#36234 [Fbk-Opn]: segfault when testing property of an overloaded class in switch a statement
ID: 36234
User updated by: matt dot flaherty at hildebrand dot co dot uk
Reported By: matt dot flaherty at hildebrand dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: SUSE LINUX 10.0 (i586)
PHP Version: 4.4.2
New Comment:
Thank you for this. I'm aware that the OO implementation in PHP5 is
very different and I intend to use 5 for any serious OO development
from now on. However, there is a project I'm working on which requires
PHP 4 and needs a drop-in replacement for the PEAR DB libraries within
a third-party framework. As support for PHP 4 is still a going concern
I decided to raise this ticket. Since posting this bug report, I have
also encountered the same problem in PHP 4.3.11. Thank you again for
your response.
Previous Comments:
[2006-02-11 13:19:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-31 23:51:27] judas dot iscariote at gmail dot com
Program received signal SIGSEGV, Segmentation fault.
0x00417258 in overload_get_property
(property_reference=0x7fe61af8)
at /home/cristian/php-src/ext/overload/overload.c:363
363 if (Z_TYPE_P(overloaded_property) ==
OE_IS_OBJECT) {
(gdb) bt
#0 0x00417258 in overload_get_property
(property_reference=0x7fe61af8)
at /home/cristian/php-src/ext/overload/overload.c:363
#1 0x004e9c01 in get_overloaded_property (T=0x7fe61ae0) at
/home/cristian/php-src/Zend/zend_execute.c:970
#2 0x004e8327 in _get_zval_ptr (node=0x6a6bd0,
Ts=0x7fe614c0, should_free=0x649c10)
at /home/cristian/php-src/Zend/zend_execute.c:93
#3 0x004f2503 in zend_switch_free (opline=0x6a6ba8,
Ts=0x7fe614c0)
at /home/cristian/php-src/Zend/zend_execute.c:236
#4 0x004efe54 in execute (op_array=0x6978d0) at
/home/cristian/php-src/Zend/zend_execute.c:2053
#5 0x004d5cf5 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/cristian/php-src/Zend/zend.c:934
#6 0x00498774 in php_execute_script
(primary_file=0x7fe64750) at
/home/cristian/php-src/main/main.c:1753
#7 0x004f50eb in main (argc=2, argv=0x7fe648b8) at
/home/cristian/php-src/sapi/cli/php_cli.c:830
./sapi/cli/php -v
PHP 4.4.3-dev (cli) (built: Jan 31 2006 19:48:51) (DEBUG)
[2006-01-31 18:30:29] matt dot flaherty at hildebrand dot co dot uk
Almost forgot. PHP is configured in the standard way for this distro:
./configure --prefix=/usr --datadir=/usr/share/php
--mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share
--includedir=/usr/include --sysconfdir=/etc --with-_lib=lib
--with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin
--disable-debug --enable-inline-optimization --enable-memory-limit
--enable-magic-quotes --enable-safe-mode --enable-sigchild
--disable-ctype --disable-session --without-mysql --disable-cli
--without-pear --with-openssl --with-apxs2=/usr/sbin/apxs2-prefork
i586-suse-linux
[2006-01-31 18:22:51] matt dot flaherty at hildebrand dot co dot uk
Description:
Apologies in advance if this turns out to be user error, but it seems
odd to me. A segmentation fault occurs when evaluating in a switch
statement an instance property of an overloaded class with which has a
__get() method. It does not matter whether the evaluated property is
native to the instance or overloaded. Also, native and overloaded
properties on an overloaded class instance don't like to be passed by
reference.
If you change the switch statements to cast the argument to (string),
as in switch ((string)$decorator-bar) { (a memory copy), then the
expected result occurs. If you leave either of the switch statements
alone there is a crash. Interestingly, with both of the switch
statements fixed and the block uncommented that calls function
reverse_me, the output looks like this:
%
I can see that the value of bar is 'bar' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Fatal error: Only variables can be passed by reference in
/srv/www/htdocs/seagull/www/crash.php on line 54
%
This is a native property on the instance so I can't understand why
passing by reference is bad. Turning off overloading produces the
expected result there, which is this:
%
I can see that the value of bar is '' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Just passed by myVar by reference and reversed the string. The value is
now enim
#36234 [NEW]: segfault when testing property of an overloaded class in switch a statement
From: matt dot flaherty at hildebrand dot co dot uk
Operating system: SUSE LINUX 10.0 (i586)
PHP version: 4.4.2
PHP Bug Type: Reproducible crash
Bug description: segfault when testing property of an overloaded class in
switch a statement
Description:
Apologies in advance if this turns out to be user error, but it seems odd
to me. A segmentation fault occurs when evaluating in a switch statement
an instance property of an overloaded class with which has a __get()
method. It does not matter whether the evaluated property is native to the
instance or overloaded. Also, native and overloaded properties on an
overloaded class instance don't like to be passed by reference.
If you change the switch statements to cast the argument to (string), as
in switch ((string)$decorator-bar) { (a memory copy), then the expected
result occurs. If you leave either of the switch statements alone there is
a crash. Interestingly, with both of the switch statements fixed and the
block uncommented that calls function reverse_me, the output looks like
this:
%
I can see that the value of bar is 'bar' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Fatal error: Only variables can be passed by reference in
/srv/www/htdocs/seagull/www/crash.php on line 54
%
This is a native property on the instance so I can't understand why
passing by reference is bad. Turning off overloading produces the expected
result there, which is this:
%
I can see that the value of bar is '' and the value of myVar is 'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Just passed by myVar by reference and reversed the string. The value is
now enim
I am not expecting a switch statemtent on bar to segfault.
Switch says the value of bar is not 'bar'. It's 'baz'.
I am not expecting a switch statemtent on myVar to segfault.
Switch says the value of myVar is not 'mine'. It's 'yours'.
%
I have observed this behaviour in php 4.4.0 and 4.4.2. Very strange.
Reproduce code:
---
http://www.jellybee.co.uk/overload_fault.txt
Expected result:
I can see that the value of bar is 'bar' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
I am not expecting a switch statemtent on bar to segfault.
Switch says the value of bar is not 'bar'. It's 'baz'.
I am not expecting a switch statemtent on myVar to segfault.
Switch says the value of myVar is not 'mine'. It's 'yours'.
Actual result:
--
Last few lines of Apache2 strace...
open(/srv/www/htdocs/seagull/www/crash.php, O_RDONLY) = 35
fstat64(35, {st_mode=S_IFREG|0644, st_size=2110, ...}) = 0
fstat64(35, {st_mode=S_IFREG|0644, st_size=2110, ...}) = 0
lseek(35, 0, SEEK_CUR) = 0
lseek(35, 0, SEEK_SET) = 0
read(35, ?php\nclass Decorator_Foo {\n..., 8192) = 2110
brk(0x8045f000) = 0x8045f000
read(35, , 8192) = 0
close(35) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
chdir(/srv/www) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
kill(18058, SIGSEGV)= 0
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
--
Edit bug report at http://bugs.php.net/?id=36234edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36234r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36234r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36234r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36234r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36234r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36234r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36234r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36234r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36234r=support
Expected behavior:http://bugs.php.net/fix.php?id=36234r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36234r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36234r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36234r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36234r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36234r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36234r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36234r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36234r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36234r=nozend
MySQL Configuration Error:http
#36234 [Opn]: segfault when testing property of an overloaded class in switch a statement
ID: 36234
User updated by: matt dot flaherty at hildebrand dot co dot uk
Reported By: matt dot flaherty at hildebrand dot co dot uk
Status: Open
Bug Type: Reproducible crash
Operating System: SUSE LINUX 10.0 (i586)
PHP Version: 4.4.2
New Comment:
Almost forgot. PHP is configured in the standard way for this distro:
./configure --prefix=/usr --datadir=/usr/share/php
--mandir=/usr/share/man --bindir=/usr/bin --libdir=/usr/share
--includedir=/usr/include --sysconfdir=/etc --with-_lib=lib
--with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin
--disable-debug --enable-inline-optimization --enable-memory-limit
--enable-magic-quotes --enable-safe-mode --enable-sigchild
--disable-ctype --disable-session --without-mysql --disable-cli
--without-pear --with-openssl --with-apxs2=/usr/sbin/apxs2-prefork
i586-suse-linux
Previous Comments:
[2006-01-31 18:22:51] matt dot flaherty at hildebrand dot co dot uk
Description:
Apologies in advance if this turns out to be user error, but it seems
odd to me. A segmentation fault occurs when evaluating in a switch
statement an instance property of an overloaded class with which has a
__get() method. It does not matter whether the evaluated property is
native to the instance or overloaded. Also, native and overloaded
properties on an overloaded class instance don't like to be passed by
reference.
If you change the switch statements to cast the argument to (string),
as in switch ((string)$decorator-bar) { (a memory copy), then the
expected result occurs. If you leave either of the switch statements
alone there is a crash. Interestingly, with both of the switch
statements fixed and the block uncommented that calls function
reverse_me, the output looks like this:
%
I can see that the value of bar is 'bar' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Fatal error: Only variables can be passed by reference in
/srv/www/htdocs/seagull/www/crash.php on line 54
%
This is a native property on the instance so I can't understand why
passing by reference is bad. Turning off overloading produces the
expected result there, which is this:
%
I can see that the value of bar is '' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
Just passed by myVar by reference and reversed the string. The value is
now enim
I am not expecting a switch statemtent on bar to segfault.
Switch says the value of bar is not 'bar'. It's 'baz'.
I am not expecting a switch statemtent on myVar to segfault.
Switch says the value of myVar is not 'mine'. It's 'yours'.
%
I have observed this behaviour in php 4.4.0 and 4.4.2. Very strange.
Reproduce code:
---
http://www.jellybee.co.uk/overload_fault.txt
Expected result:
I can see that the value of bar is 'bar' and the value of myVar is
'mine'.
I've tested === and that worked okay.
So did ==.
subst function is okay too.
I am not expecting a switch statemtent on bar to segfault.
Switch says the value of bar is not 'bar'. It's 'baz'.
I am not expecting a switch statemtent on myVar to segfault.
Switch says the value of myVar is not 'mine'. It's 'yours'.
Actual result:
--
Last few lines of Apache2 strace...
open(/srv/www/htdocs/seagull/www/crash.php, O_RDONLY) = 35
fstat64(35, {st_mode=S_IFREG|0644, st_size=2110, ...}) = 0
fstat64(35, {st_mode=S_IFREG|0644, st_size=2110, ...}) = 0
lseek(35, 0, SEEK_CUR) = 0
lseek(35, 0, SEEK_SET) = 0
read(35, ?php\nclass Decorator_Foo {\n..., 8192) = 2110
brk(0x8045f000) = 0x8045f000
read(35, , 8192) = 0
close(35) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
chdir(/srv/www) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
kill(18058, SIGSEGV)= 0
sigreturn() = ? (mask now [])
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
--
Edit this bug report at http://bugs.php.net/?id=36234edit=1
#29417 [Com]: Type hints do not allow for extended interfaces
ID: 29417
Comment by: matt at builtfromsource dot com
Reported By: ah08010-zend at yahoo dot com
Status: Suspended
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5.0.0
Assigned To: hellz
New Comment:
Well, I just ran into this problem as well. Looks like it's been
around for awhile. Any fix on the horizon?
Previous Comments:
[2004-07-28 05:58:12] [EMAIL PROTECTED]
Wow it seems you'd be the first person answering my OOP test question
correctly. Anyway structer is the wrong word here but you are right.
The code you have here should work. If you wanna experiment with that
you can try this patch:
http://marcus-boerger.de/php/ext/ze2/ze2-type-hint-classes-20040719.diff.txt
But though it works in CLI this is not even a proof of concept.
[2004-07-28 03:41:39] ah08010-zend at yahoo dot com
Description:
Type hints in a derived class
that specify a function parameter
implements an interface
derived from the interface
specified in the (other) interface
implemented by the base class
(whew!)
are flagged as an error despite being type-compatible:
Fatal error: Declaration of TranslatedPlural::compose() must be
compatible with that of Translatable::compose() in
...\TranslatedMessage.php on line 83
Reproduce code:
---
// Parameter type hint (BASE)
interface TranslationMap
{
public function fetch($the_key);
}
// Parameter type hint (DERIVED)
interface TranslationLexicon
extends TranslationMap
{
public function plural($the_noun, $the_count);
}
// Implementation Interface
interface Translatable
{
function set_args();
function compose(TranslationMap $map);
}
// Base class
class TranslatedMessage
implements Translatable
{
public function set_args()
{
}
public function compose(TranslationMap $lex)
{
}
}
// Derived class
class TranslatedPlural
extends TranslatedMessage
{
public function compose(TranslationLexicon $lex)
{
}
}
Expected result:
I expect that the derived class, TranslatedPlural, will be checked for
a stricter (but type-compatible) interface than the base class.
Actual result:
--
Fatal error: Declaration of TranslatedPlural::compose() must be
compatible with that of Translatable::compose() in
...\TranslatedMessage.php on line 83
--
Edit this bug report at http://bugs.php.net/?id=29417edit=1
#35957 [NEW]: Array literal syntax support
From: matt at matttoddphoto dot com
Operating system: Any
PHP version: 6CVS-2006-01-10 (snap)
PHP Bug Type: Feature/Change Request
Bug description: Array literal syntax support
Description:
It would be lovely to be able to literally define arrays with
simple syntax like the following:
[one, two, three]
instead of the less intuitive:
array(one, two, three);
This would simplify creating arrays of arrays (of arrays)
inline for functions. Also, this would help solve the 'named
parameters' request by allowing for an associative array to be
given simply by throwing []s in.
Reproduce code:
---
Here is an example just for the sake of clarity:
$validate = [$_POST['post'], ['title'='/[A-Za-z0-9_\?\!\.\#\\%]+/',
text='/\w*/', 'user_id'='/\d+/']];
This would be in opposition to:
$validate = array($_POST['post'],
array('title'='/[A-Za-z0-9_\?\!\.\#\\%]+/', text='/.*/',
'user_id'='/\d+/'));
You can see how more complex examples can get just that much more complex
(the the nth degree).
--
Edit bug report at http://bugs.php.net/?id=35957edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=35957r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=35957r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=35957r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=35957r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=35957r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35957r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=35957r=needscript
Try newer version:http://bugs.php.net/fix.php?id=35957r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35957r=support
Expected behavior:http://bugs.php.net/fix.php?id=35957r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35957r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35957r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=35957r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35957r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=35957r=dst
IIS Stability:http://bugs.php.net/fix.php?id=35957r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35957r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35957r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35957r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=35957r=mysqlcfg
#33931 [Com]: __get and __set don't handle arrays correctly
ID: 33931
Comment by: matt at matttoddphoto dot com
Reported By: wkonkel at gmail dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5CVS-2005-08-19
Assigned To: dmitry
New Comment:
I have had the same problem. This is terrible in the sense
that I'd love to have this work, yet it doesn't. Shame.
When I have:
class Response {
private $collection;
public function __set($name, $value) {
$this-collection[$name] = $value;
}
public function __get($name) {
return $this-collection[$name];
}
}
The following does not assign anything but empty array()s
into the private $collection property.
For instance (which is called from within another class,
hence the $this reference):
foreach($posts as $post) {
$this-response-posts[$post['id']] = $post;
}
Now,
print_r($this-response-posts);
will output:
Array();
N.B. -- I had not noticed the bizarre activity with the
properties reappearing in sequence immediately. In fact, I
couldn't explain the bizarre behavior for two separate,
nearly-identical loops like this one resulted in all of the
data in the final of the two. Now I understand why it was
combining the two. Bizarre indeed!
Previous Comments:
[2005-09-24 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.
[2005-09-17 00:48:23] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
I'm unable to replicate it anymore.
[2005-08-01 09:51:38] [EMAIL PROTECTED]
Dmitry, could you check it plz ?
[2005-07-31 20:01:33] [EMAIL PROTECTED]
And this with Sean's code:
PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line
8
Notice: Undefined property: A::$foo in /home/jani/t.php on line 8
PHP Notice: Undefined property: A::$foo in /home/jani/t.php on line
9
Notice: Undefined property: A::$foo in /home/jani/t.php on line 9
PHP Notice: Undefined variable: undefined in /home/jani/t.php on line
10
Notice: Undefined variable: undefined in /home/jani/t.php on line 10
NULL
array(2) {
[bar1]=
string(5) oink1
[0]=
string(4) blah
}
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088ED84C (6
bytes), script=t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088ED80C (16
bytes), script=t.php
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088ED7B4 (40
bytes), script=t.php
Last leak repeated 1 time
/usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088ED754 (44
bytes), script=t.php
/usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was
relayed)
Last leak repeated 3 times
/usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16
bytes), script=t.php
=== Total 11 memory leaks detected ===
[2005-07-31 20:00:32] [EMAIL PROTECTED]
Output with CVS HEAD:
Array
(
[foo2] = bar2
[foo3] = bar3
[0] = blah
)
/usr/src/php/php5/Zend/zend_hash.c(242) : Freeing 0x088EF6FC (40
bytes), script=t.php
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_variables.h(45) : Freeing 0x088EF664 (5
bytes), script=t.php
/usr/src/php/php5/Zend/zend_variables.c(120) : Actual location
(location was relayed)
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_execute.c(798) : Freeing 0x088EF624 (16
bytes), script=t.php
Last leak repeated 2 times
/usr/src/php/php5/Zend/zend_execute.c(1031) : Freeing 0x088EF56C (44
bytes), script=t.php
/usr/src/php/php5/Zend/zend_API.c(712) : Actual location (location was
relayed)
Last leak repeated 3 times
/usr/src/php/php5/Zend/zend_execute.c(1028) : Freeing 0x088DE7CC (16
bytes), script=t.php
=== Total 14 memory leaks detected ===
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/33931
--
Edit this bug report at http://bugs.php.net/?id=33931edit=1
#35896 [NEW]: Round() not doing what it says on the tin
From: matt at equaliser dot net Operating system: Linux PHP version: 4.4.1 PHP Bug Type: *Math Functions Bug description: Round() not doing what it says on the tin Description: I know *why* this is happening - so please don't point me to http://www.php.net/manual/en/language.types.float.php - I'm aware of this. This does not change the fact that a pure call to the round() function using a float value stored in memory can return the wrong result. The fact that this is easily fixed by rounding to one decimal place further along the float before performing the actual rounding, simply makes the continued existence of this bug more baffling. Why doesn't PHP round() do this internally? Do all PHP developers need to roll their own round() function if they are going to guarantee mathematical accuracy? Reproduce code: --- ?php $input_value = 45; $vat = $input_value * .175; echo $vat . 'br /'; echo round($vat , 2) . 'br /'; echo round(strval($vat) , 2) . 'br /'; echo round(round($vat , 3) , 2) . 'br /'; $input_value2 = 7.875; echo round($input_value2 , 2) . 'br /'; echo round(7.875 , 2) . 'br /'; echo $vat - $input_value2; ? Expected result: 7.875 7.87 7.88 7.88 7.88 7.88 -8.8817841970013E-16 Actual result: -- 7.875 7.88 7.88 7.88 7.88 7.88 -8.8817841970013E-16 -- Edit bug report at http://bugs.php.net/?id=35896edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=35896r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=35896r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=35896r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=35896r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=35896r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35896r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=35896r=needscript Try newer version:http://bugs.php.net/fix.php?id=35896r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35896r=support Expected behavior:http://bugs.php.net/fix.php?id=35896r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35896r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35896r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=35896r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35896r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=35896r=dst IIS Stability:http://bugs.php.net/fix.php?id=35896r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35896r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35896r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35896r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=35896r=mysqlcfg
#35896 [Opn]: Round() not doing what it says on the tin
ID: 35896 User updated by: matt at equaliser dot net Reported By: matt at equaliser dot net Status: Open Bug Type: *Math Functions Operating System: Linux PHP Version: 4.4.1 New Comment: Soory - I got the expected result and the actual result interposed in my previous posting. Previous Comments: [2006-01-04 20:30:50] matt at equaliser dot net Description: I know *why* this is happening - so please don't point me to http://www.php.net/manual/en/language.types.float.php - I'm aware of this. This does not change the fact that a pure call to the round() function using a float value stored in memory can return the wrong result. The fact that this is easily fixed by rounding to one decimal place further along the float before performing the actual rounding, simply makes the continued existence of this bug more baffling. Why doesn't PHP round() do this internally? Do all PHP developers need to roll their own round() function if they are going to guarantee mathematical accuracy? Reproduce code: --- ?php $input_value = 45; $vat = $input_value * .175; echo $vat . 'br /'; echo round($vat , 2) . 'br /'; echo round(strval($vat) , 2) . 'br /'; echo round(round($vat , 3) , 2) . 'br /'; $input_value2 = 7.875; echo round($input_value2 , 2) . 'br /'; echo round(7.875 , 2) . 'br /'; echo $vat - $input_value2; ? Expected result: 7.875 7.87 7.88 7.88 7.88 7.88 -8.8817841970013E-16 Actual result: -- 7.875 7.88 7.88 7.88 7.88 7.88 -8.8817841970013E-16 -- Edit this bug report at http://bugs.php.net/?id=35896edit=1
#35896 [Bgs]: Round() not doing what it says on the tin
ID: 35896 User updated by: matt at equaliser dot net Reported By: matt at equaliser dot net Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 4.4.1 New Comment: I *KNOW* floating point numbers have limited precision, but surely the round() function *IS* supposed to have absolute precision? this is not a BOGUS bug: float() Still does not do what the documentation says it does. There's 2 ways of looking at this; either: 1] round() is incorrectly documented, and it should be made clear that the round operation is being performed on a number slightly different that the one apparently represented by the variable. or: 2] round() should be returning a correctly rounded number which conforms to the string representation of its input variable. I can roll a very simple fix myself simply by doing one of the following: round((strval($var) , [precision]) - Take the var out of its float representation, instead using its string representation, then allowing php to convert this string back to a float before rounding. round(round($var , [precision+1]) , [precision]) - Round the value to [precision+1] before performing the actual rounding, thus removing any fuzziness from the end of the float before actually rounding it. Both of the above appear to work. What still baffles me is that the PHP manual implies that it has already taken care of this kind of stuff, and is going to return me a rounded version of the input I'm giving it, whereas what it is apparently doing is returning the rounded version of my $vars current representation in the FPU. for this situation to persist seems wilfully perverse on Zend's part. Surely this should either be fixed, or properly documented? Previous Comments: [2006-01-04 20:39:19] [EMAIL PROTECTED] Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about floats and what IEEE 754 is read this: http://docs.sun.com/source/806-3568/ncg_goldberg.html Thank you for your interest in PHP. [2006-01-04 20:37:21] matt at equaliser dot net Soory - I got the expected result and the actual result interposed in my previous posting. [2006-01-04 20:30:50] matt at equaliser dot net Description: I know *why* this is happening - so please don't point me to http://www.php.net/manual/en/language.types.float.php - I'm aware of this. This does not change the fact that a pure call to the round() function using a float value stored in memory can return the wrong result. The fact that this is easily fixed by rounding to one decimal place further along the float before performing the actual rounding, simply makes the continued existence of this bug more baffling. Why doesn't PHP round() do this internally? Do all PHP developers need to roll their own round() function if they are going to guarantee mathematical accuracy? Reproduce code: --- ?php $input_value = 45; $vat = $input_value * .175; echo $vat . 'br /'; echo round($vat , 2) . 'br /'; echo round(strval($vat) , 2) . 'br /'; echo round(round($vat , 3) , 2) . 'br /'; $input_value2 = 7.875; echo round($input_value2 , 2) . 'br /'; echo round(7.875 , 2) . 'br /'; echo $vat - $input_value2; ? Expected result: 7.875 7.87 7.88 7.88 7.88 7.88 -8.8817841970013E-16 Actual result: -- 7.875 7.88 7.88 7.88 7.88 7.88 -8.8817841970013E-16 -- Edit this bug report at http://bugs.php.net/?id=35896edit=1
#35142 [Csd]: SOAP Client/Server Complex Object Support
ID: 35142
User updated by: matt dot jones at plumgroup dot com
Reported By: matt dot jones at plumgroup dot com
Status: Closed
Bug Type: SOAP related
Operating System: *
PHP Version: 5CVS-2005-11-07 (snap)
Assigned To: dmitry
New Comment:
Thanks, this works perfectly! Just a heads up to people using this
patch though:
You must clear out your WSDL cache for the patch to override the
previous incorrect behavior.
Previous Comments:
[2005-11-08 09:37:05] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_1.
[2005-11-08 00:54:42] [EMAIL PROTECTED]
Assigned to the maintainer of ext/soap
[2005-11-08 00:07:02] matt dot jones at plumgroup dot com
I have tested this with php5-win32-latest.zip (it was easier than
recompiling for linux) and I am seeing the exact same behavior.
Providing an array of objects is not interpreted properly and having
more than one subtag object results in the first tag to appear in the
WSDL being the only response.
[2005-11-07 21:39:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-11-07 18:47:26] matt dot jones at plumgroup dot com
Description:
When implementing a function to handle a soap request in a SoapServer
the object that is returned has a specific and obvious structure. It
is an object with basic typed members to represent the attributes and
one or more complex objects (or an array of objects) for subtags which
are built as a similar sort of object.
What I am proposing would be to allow for this same complex object
structure to be passed in and parsed by both the
SoapClient-{function()} and to be returned by the functions specified
to handle the soap request for the SoapServer.
Reproduce code:
---
The following is some partial source code that represents how I would
like to see objects supported in the client-side:
http://roberts.plumgroup.com/~mjones/soapclient.txt
You can see that there are multiple classes created to contruct the
request. The code makes use of both single objects and arrays of
objects to create a complex request. You can find a version of the
WSDL that this is partially implementing here:
http://roberts.plumgroup.com/~mjones/test.wsdl
Expected result:
The system should be able to accept this format for incoming objects to
properly create a complex soap request such as:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns1=http://testurl/Message;
SOAP-ENV:Body
ns1:ivrEvents activityId=101 messageId=12345 source=IVR
version=1.0
logOnEvent audienceMemberId=34567
timestamp=2005-11-07T12:27:33/
logOffEvent audienceMemberId=34568
timestamp=2005-11-07T12:27:33 smokeStatus=Smoked
callInitiator=IVR/
logOffEvent audienceMemberId=34569
timestamp=2005-11-07T12:27:33 smokeStatus=SmokeFree
callInitiator=IVR/
/ns1:ivrEvents
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This is the format it chooses for objects sent to SoapServer handler
functions, it should support it for SoapClient function calls.
Actual result:
--
With the above code the current implementation properly creates the
logOnEvent subtag and stops there no logOffEvents are added. If you
attempt to add multiple logOnEvents alone in an array they are not
properly added as multiple logOnEvents either.
--
Edit this bug report at http://bugs.php.net/?id=35142edit=1
#35142 [NEW]: SOAP Client/Server Complex Object Support
From: matt dot jones at plumgroup dot com
Operating system: *
PHP version: 5.0.5
PHP Bug Type: Feature/Change Request
Bug description: SOAP Client/Server Complex Object Support
Description:
When implementing a function to handle a soap request in a SoapServer the
object that is returned has a specific and obvious structure. It is an
object with basic typed members to represent the attributes and one or
more complex objects (or an array of objects) for subtags which are built
as a similar sort of object.
What I am proposing would be to allow for this same complex object
structure to be passed in and parsed by both the SoapClient-{function()}
and to be returned by the functions specified to handle the soap request
for the SoapServer.
Reproduce code:
---
The following is some partial source code that represents how I would like
to see objects supported in the client-side:
http://roberts.plumgroup.com/~mjones/soapclient.txt
You can see that there are multiple classes created to contruct the
request. The code makes use of both single objects and arrays of objects
to create a complex request. You can find a version of the WSDL that this
is partially implementing here:
http://roberts.plumgroup.com/~mjones/test.wsdl
Expected result:
The system should be able to accept this format for incoming objects to
properly create a complex soap request such as:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns1=http://testurl/Message;
SOAP-ENV:Body
ns1:ivrEvents activityId=101 messageId=12345 source=IVR
version=1.0
logOnEvent audienceMemberId=34567
timestamp=2005-11-07T12:27:33/
logOffEvent audienceMemberId=34568
timestamp=2005-11-07T12:27:33 smokeStatus=Smoked
callInitiator=IVR/
logOffEvent audienceMemberId=34569
timestamp=2005-11-07T12:27:33 smokeStatus=SmokeFree
callInitiator=IVR/
/ns1:ivrEvents
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This is the format it chooses for objects sent to SoapServer handler
functions, it should support it for SoapClient function calls.
Actual result:
--
With the above code the current implementation properly creates the
logOnEvent subtag and stops there no logOffEvents are added. If you
attempt to add multiple logOnEvents alone in an array they are not
properly added as multiple logOnEvents either.
--
Edit bug report at http://bugs.php.net/?id=35142edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35142r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35142r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35142r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35142r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35142r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35142r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35142r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35142r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35142r=support
Expected behavior: http://bugs.php.net/fix.php?id=35142r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35142r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35142r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35142r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35142r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35142r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35142r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35142r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35142r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35142r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35142r=mysqlcfg
#35142 [Opn]: SOAP Client/Server Complex Object Support
ID: 35142
User updated by: matt dot jones at plumgroup dot com
Reported By: matt dot jones at plumgroup dot com
Status: Open
-Bug Type: Feature/Change Request
+Bug Type: SOAP related
Operating System: *
PHP Version: 5.0.5
New Comment:
Moved to the SOAP related category
Previous Comments:
[2005-11-07 18:47:26] matt dot jones at plumgroup dot com
Description:
When implementing a function to handle a soap request in a SoapServer
the object that is returned has a specific and obvious structure. It
is an object with basic typed members to represent the attributes and
one or more complex objects (or an array of objects) for subtags which
are built as a similar sort of object.
What I am proposing would be to allow for this same complex object
structure to be passed in and parsed by both the
SoapClient-{function()} and to be returned by the functions specified
to handle the soap request for the SoapServer.
Reproduce code:
---
The following is some partial source code that represents how I would
like to see objects supported in the client-side:
http://roberts.plumgroup.com/~mjones/soapclient.txt
You can see that there are multiple classes created to contruct the
request. The code makes use of both single objects and arrays of
objects to create a complex request. You can find a version of the
WSDL that this is partially implementing here:
http://roberts.plumgroup.com/~mjones/test.wsdl
Expected result:
The system should be able to accept this format for incoming objects to
properly create a complex soap request such as:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns1=http://testurl/Message;
SOAP-ENV:Body
ns1:ivrEvents activityId=101 messageId=12345 source=IVR
version=1.0
logOnEvent audienceMemberId=34567
timestamp=2005-11-07T12:27:33/
logOffEvent audienceMemberId=34568
timestamp=2005-11-07T12:27:33 smokeStatus=Smoked
callInitiator=IVR/
logOffEvent audienceMemberId=34569
timestamp=2005-11-07T12:27:33 smokeStatus=SmokeFree
callInitiator=IVR/
/ns1:ivrEvents
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This is the format it chooses for objects sent to SoapServer handler
functions, it should support it for SoapClient function calls.
Actual result:
--
With the above code the current implementation properly creates the
logOnEvent subtag and stops there no logOffEvents are added. If you
attempt to add multiple logOnEvents alone in an array they are not
properly added as multiple logOnEvents either.
--
Edit this bug report at http://bugs.php.net/?id=35142edit=1
#35142 [Fbk-Opn]: SOAP Client/Server Complex Object Support
ID: 35142
User updated by: matt dot jones at plumgroup dot com
Reported By: matt dot jones at plumgroup dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: *
PHP Version: 5.0.5
New Comment:
I have tested this with php5-win32-latest.zip (it was easier than
recompiling for linux) and I am seeing the exact same behavior.
Providing an array of objects is not interpreted properly and having
more than one subtag object results in the first tag to appear in the
WSDL being the only response.
Previous Comments:
[2005-11-07 21:39:17] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-11-07 18:47:26] matt dot jones at plumgroup dot com
Description:
When implementing a function to handle a soap request in a SoapServer
the object that is returned has a specific and obvious structure. It
is an object with basic typed members to represent the attributes and
one or more complex objects (or an array of objects) for subtags which
are built as a similar sort of object.
What I am proposing would be to allow for this same complex object
structure to be passed in and parsed by both the
SoapClient-{function()} and to be returned by the functions specified
to handle the soap request for the SoapServer.
Reproduce code:
---
The following is some partial source code that represents how I would
like to see objects supported in the client-side:
http://roberts.plumgroup.com/~mjones/soapclient.txt
You can see that there are multiple classes created to contruct the
request. The code makes use of both single objects and arrays of
objects to create a complex request. You can find a version of the
WSDL that this is partially implementing here:
http://roberts.plumgroup.com/~mjones/test.wsdl
Expected result:
The system should be able to accept this format for incoming objects to
properly create a complex soap request such as:
?xml version=1.0 encoding=UTF-8?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ns1=http://testurl/Message;
SOAP-ENV:Body
ns1:ivrEvents activityId=101 messageId=12345 source=IVR
version=1.0
logOnEvent audienceMemberId=34567
timestamp=2005-11-07T12:27:33/
logOffEvent audienceMemberId=34568
timestamp=2005-11-07T12:27:33 smokeStatus=Smoked
callInitiator=IVR/
logOffEvent audienceMemberId=34569
timestamp=2005-11-07T12:27:33 smokeStatus=SmokeFree
callInitiator=IVR/
/ns1:ivrEvents
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This is the format it chooses for objects sent to SoapServer handler
functions, it should support it for SoapClient function calls.
Actual result:
--
With the above code the current implementation properly creates the
logOnEvent subtag and stops there no logOffEvents are added. If you
attempt to add multiple logOnEvents alone in an array they are not
properly added as multiple logOnEvents either.
--
Edit this bug report at http://bugs.php.net/?id=35142edit=1
#33685 [WFx]: configure: error: libjpeg.(a|so) not found.
ID: 33685 User updated by: matt at azoogleads dot com Reported By: matt at azoogleads dot com Status: Wont fix Bug Type: PHP options/info functions Operating System: RHEL 4 ES/x86_64 PHP Version: 4.4.0 New Comment: I created the symlinks you mentioned which got around the libjpeg issue (thanks!), only to run into the error configure: error: freetype2 not found! I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and --with-freetype-dir without any luck. Am I going to run into trouble if I run PHP 4.4.0 under 64-bit Linux? Previous Comments: [2005-07-14 01:18:27] [EMAIL PROTECTED] I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current CVS HEAD). It will not be fixed in PHP 4. Workaround: # ln -s /usr/include /opt/include # ln -s /usr/lib64 /opt/lib And use these options and values for them: --with-mysql=/opt --with-jpeg-dir=/opt --with-png-dir=/opt [2005-07-13 23:08:24] matt at azoogleads dot com I wasn't able to make out anything obvious in the config.log file (searching for any reference to 'jpeg'). Here's a copy of config.log for your reference: http://ca.geocities.com/[EMAIL PROTECTED]/config.log [2005-07-13 22:45:45] [EMAIL PROTECTED] Check the config.log for the real reason why the check failed. Configure outputs 'checking for the location of libjpeg... yes' because you have '--with-jpeg-dir', not that it found it. [2005-07-13 22:10:29] matt at azoogleads dot com Description: I'm having the same problem described in Bug #32369, where I'm trying to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the location of libjpeg is detected (see below), and both libjpeg.so and libjpeg.a files exist under /usr/lib64, the configure script terminates with the error configure: error: libjpeg.(a|so) not found. This also seem to occur with PHP 4.3.11. configure snip checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... yes checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. /configure snip Specifying --with-jpeg-dir=/usr or --with-jpeg-dir=/usr/lib64 doesn't fix the problem. Reproduce code: --- ./configure --with-mysql=/usr \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-zlib \ --with-ftp \ --with-gd \ --with-jpeg-dir \ --with-freetype-dir \ --enable-pcntl \ --with-openssl --with-curl \ --with-dom \ Actual result: -- The location of libjpeg will be detected, however the configure script will terminate with the error configure: error: libjpeg.(a|so) not found. -- Edit this bug report at http://bugs.php.net/?id=33685edit=1
#33685 [WFx]: configure: error: libjpeg.(a|so) not found.
ID: 33685 User updated by: matt at azoogleads dot com Reported By: matt at azoogleads dot com Status: Wont fix Bug Type: PHP options/info functions Operating System: RHEL 4 ES/x86_64 PHP Version: 4.4.0 New Comment: Please disregard my last post, all is fine. I didn't have the freetype-devel package installed ;-) Previous Comments: [2005-07-14 16:06:10] matt at azoogleads dot com I created the symlinks you mentioned which got around the libjpeg issue (thanks!), only to run into the error configure: error: freetype2 not found! I've tried using --with-freetype-dir=/opt, --with-freetype-dir=/usr and --with-freetype-dir without any luck. Am I going to run into trouble if I run PHP 4.4.0 under 64-bit Linux? [2005-07-14 01:18:27] [EMAIL PROTECTED] I didn't notice the x86_64 there. This bug is fixed in PHP 5.1 (current CVS HEAD). It will not be fixed in PHP 4. Workaround: # ln -s /usr/include /opt/include # ln -s /usr/lib64 /opt/lib And use these options and values for them: --with-mysql=/opt --with-jpeg-dir=/opt --with-png-dir=/opt [2005-07-13 23:08:24] matt at azoogleads dot com I wasn't able to make out anything obvious in the config.log file (searching for any reference to 'jpeg'). Here's a copy of config.log for your reference: http://ca.geocities.com/[EMAIL PROTECTED]/config.log [2005-07-13 22:45:45] [EMAIL PROTECTED] Check the config.log for the real reason why the check failed. Configure outputs 'checking for the location of libjpeg... yes' because you have '--with-jpeg-dir', not that it found it. [2005-07-13 22:10:29] matt at azoogleads dot com Description: I'm having the same problem described in Bug #32369, where I'm trying to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the location of libjpeg is detected (see below), and both libjpeg.so and libjpeg.a files exist under /usr/lib64, the configure script terminates with the error configure: error: libjpeg.(a|so) not found. This also seem to occur with PHP 4.3.11. configure snip checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... yes checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. /configure snip Specifying --with-jpeg-dir=/usr or --with-jpeg-dir=/usr/lib64 doesn't fix the problem. Reproduce code: --- ./configure --with-mysql=/usr \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-zlib \ --with-ftp \ --with-gd \ --with-jpeg-dir \ --with-freetype-dir \ --enable-pcntl \ --with-openssl --with-curl \ --with-dom \ Actual result: -- The location of libjpeg will be detected, however the configure script will terminate with the error configure: error: libjpeg.(a|so) not found. -- Edit this bug report at http://bugs.php.net/?id=33685edit=1
#33685 [NEW]: configure: error: libjpeg.(a|so) not found.
From: matt at azoogleads dot com Operating system: RHEL 4 ES/x86_64 PHP version: 4.4.0 PHP Bug Type: PHP options/info functions Bug description: configure: error: libjpeg.(a|so) not found. Description: I'm having the same problem described in Bug #32369, where I'm trying to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the location of libjpeg is detected (see below), and both libjpeg.so and libjpeg.a files exist under /usr/lib64, the configure script terminates with the error configure: error: libjpeg.(a|so) not found. This also seem to occur with PHP 4.3.11. configure snip checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... yes checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. /configure snip Specifying --with-jpeg-dir=/usr or --with-jpeg-dir=/usr/lib64 doesn't fix the problem. Reproduce code: --- ./configure --with-mysql=/usr \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-zlib \ --with-ftp \ --with-gd \ --with-jpeg-dir \ --with-freetype-dir \ --enable-pcntl \ --with-openssl --with-curl \ --with-dom \ Actual result: -- The location of libjpeg will be detected, however the configure script will terminate with the error configure: error: libjpeg.(a|so) not found. -- Edit bug report at http://bugs.php.net/?id=33685edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33685r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33685r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33685r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33685r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33685r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33685r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33685r=needscript Try newer version: http://bugs.php.net/fix.php?id=33685r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33685r=support Expected behavior: http://bugs.php.net/fix.php?id=33685r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33685r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33685r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33685r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33685r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33685r=dst IIS Stability: http://bugs.php.net/fix.php?id=33685r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33685r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33685r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33685r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33685r=mysqlcfg
#33685 [Bgs-Opn]: configure: error: libjpeg.(a|so) not found.
ID: 33685 User updated by: matt at azoogleads dot com Reported By: matt at azoogleads dot com -Status: Bogus +Status: Open Bug Type: PHP options/info functions Operating System: RHEL 4 ES/x86_64 PHP Version: 4.4.0 New Comment: I wasn't able to make out anything obvious in the config.log file (searching for any reference to 'jpeg'). Here's a copy of config.log for your reference: http://ca.geocities.com/[EMAIL PROTECTED]/config.log Previous Comments: [2005-07-13 22:45:45] [EMAIL PROTECTED] Check the config.log for the real reason why the check failed. Configure outputs 'checking for the location of libjpeg... yes' because you have '--with-jpeg-dir', not that it found it. [2005-07-13 22:10:29] matt at azoogleads dot com Description: I'm having the same problem described in Bug #32369, where I'm trying to compile JPEG support into 4.4.0 on RHEL 4 ES/x86_64 and although the location of libjpeg is detected (see below), and both libjpeg.so and libjpeg.a files exist under /usr/lib64, the configure script terminates with the error configure: error: libjpeg.(a|so) not found. This also seem to occur with PHP 4.3.11. configure snip checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 1.x support... no checking for FreeType 2... yes checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no checking for fabsf... yes checking for floorf... yes configure: error: libjpeg.(a|so) not found. /configure snip Specifying --with-jpeg-dir=/usr or --with-jpeg-dir=/usr/lib64 doesn't fix the problem. Reproduce code: --- ./configure --with-mysql=/usr \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-zlib \ --with-ftp \ --with-gd \ --with-jpeg-dir \ --with-freetype-dir \ --enable-pcntl \ --with-openssl --with-curl \ --with-dom \ Actual result: -- The location of libjpeg will be detected, however the configure script will terminate with the error configure: error: libjpeg.(a|so) not found. -- Edit this bug report at http://bugs.php.net/?id=33685edit=1
#33028 [Bgs]: mime_content_type returns inaccurate Office content types
ID: 33028 User updated by: matt at kanchi dot org Reported By: matt at kanchi dot org Status: Bogus Bug Type: Filesystem function related Operating System: OS X PHP Version: 4.3.10 New Comment: Well, I upgraded file to 4.13 (the latest version), and the MIME magic file may be more complicated but it returns the same thing. Since PHP relies on this file, wouldn't it make sense to check the extension against what the MIME magic file returns to determine if it's correct? I would think a warning would at least be warranted in the documentation until it's resolved. Who knows, maybe I'm the only one who's having this problem. Anyway, I guess I'll just manually handle Office extensions or something. Previous Comments: [2005-05-14 11:02:42] [EMAIL PROTECTED] So, the bug is not in PHP, but in your mime.magic file. No PHP bug - bogus. [2005-05-14 00:55:38] matt at kanchi dot org In case you meant file -i /path/to/file.ppt, that returns the same as mime_content_type does (in my case) for those files. -k returns only one result. [2005-05-14 00:50:38] matt at kanchi dot org Gotcha. It returns: (filename): Microsoft Office Document [2005-05-13 23:33:09] [EMAIL PROTECTED] No, I meant running this command in console. [2005-05-13 22:37:18] matt at kanchi dot org Do you mean mime_content_type(file /path/to/file)? If so, that returns the error, mime_magic: invalid mode 0156130. 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/33028 -- Edit this bug report at http://bugs.php.net/?id=33028edit=1
#33028 [NEW]: mime_content_type returns inaccurate Office content types
From: matt at kanchi dot org Operating system: OS X PHP version: 4.3.10 PHP Bug Type: Filesystem function related Bug description: mime_content_type returns inaccurate Office content types Description: Certain Office files do not return an accurate MIME content type with mime_content_type. Excel and Powerpoint, for example, return an application/msword type, while Access returns text/plain. Images, text, and Word files return correctly. These files were generated in Office 2002 for Windows. Configuration options: --with-mime-magic From php.ini: mime_magic mime_magic support = enabled Directive = Local Value = Master Value mime_magic.magicfile = /usr/share/file/magic.mime = /usr/share/file/magic.mime Reproduce code: --- mime_content_type(/some/path/to/xls-file); mime_content_type(/some/path/to/ppt-file); mime_content_type(/some/path/to/mdb-file); Expected result: application/msexcel application/mspowerpoint application/msaccess Or some variation (vnd, x-, etc.). Actual result: -- application/msword application/msword text/plain -- Edit bug report at http://bugs.php.net/?id=33028edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33028r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33028r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33028r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33028r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33028r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33028r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33028r=needscript Try newer version: http://bugs.php.net/fix.php?id=33028r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33028r=support Expected behavior: http://bugs.php.net/fix.php?id=33028r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33028r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33028r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33028r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33028r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33028r=dst IIS Stability: http://bugs.php.net/fix.php?id=33028r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33028r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33028r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33028r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33028r=mysqlcfg
#33028 [Fbk-Opn]: mime_content_type returns inaccurate Office content types
ID: 33028 User updated by: matt at kanchi dot org Reported By: matt at kanchi dot org -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: OS X PHP Version: 4.3.10 New Comment: Do you mean mime_content_type(file /path/to/file)? If so, that returns the error, mime_magic: invalid mode 0156130. Previous Comments: [2005-05-13 21:37:46] [EMAIL PROTECTED] Does this work: `file /path/to/file.ppt` ? [2005-05-13 20:12:34] matt at kanchi dot org Description: Certain Office files do not return an accurate MIME content type with mime_content_type. Excel and Powerpoint, for example, return an application/msword type, while Access returns text/plain. Images, text, and Word files return correctly. These files were generated in Office 2002 for Windows. Configuration options: --with-mime-magic From php.ini: mime_magic mime_magic support = enabled Directive = Local Value = Master Value mime_magic.magicfile = /usr/share/file/magic.mime = /usr/share/file/magic.mime Reproduce code: --- mime_content_type(/some/path/to/xls-file); mime_content_type(/some/path/to/ppt-file); mime_content_type(/some/path/to/mdb-file); Expected result: application/msexcel application/mspowerpoint application/msaccess Or some variation (vnd, x-, etc.). Actual result: -- application/msword application/msword text/plain -- Edit this bug report at http://bugs.php.net/?id=33028edit=1
#33028 [Opn]: mime_content_type returns inaccurate Office content types
ID: 33028 User updated by: matt at kanchi dot org Reported By: matt at kanchi dot org Status: Open Bug Type: Filesystem function related Operating System: OS X PHP Version: 4.3.10 New Comment: In case you meant file -i /path/to/file.ppt, that returns the same as mime_content_type does (in my case) for those files. -k returns only one result. Previous Comments: [2005-05-14 00:50:38] matt at kanchi dot org Gotcha. It returns: (filename): Microsoft Office Document [2005-05-13 23:33:09] [EMAIL PROTECTED] No, I meant running this command in console. [2005-05-13 22:37:18] matt at kanchi dot org Do you mean mime_content_type(file /path/to/file)? If so, that returns the error, mime_magic: invalid mode 0156130. [2005-05-13 21:37:46] [EMAIL PROTECTED] Does this work: `file /path/to/file.ppt` ? [2005-05-13 20:12:34] matt at kanchi dot org Description: Certain Office files do not return an accurate MIME content type with mime_content_type. Excel and Powerpoint, for example, return an application/msword type, while Access returns text/plain. Images, text, and Word files return correctly. These files were generated in Office 2002 for Windows. Configuration options: --with-mime-magic From php.ini: mime_magic mime_magic support = enabled Directive = Local Value = Master Value mime_magic.magicfile = /usr/share/file/magic.mime = /usr/share/file/magic.mime Reproduce code: --- mime_content_type(/some/path/to/xls-file); mime_content_type(/some/path/to/ppt-file); mime_content_type(/some/path/to/mdb-file); Expected result: application/msexcel application/mspowerpoint application/msaccess Or some variation (vnd, x-, etc.). Actual result: -- application/msword application/msword text/plain -- Edit this bug report at http://bugs.php.net/?id=33028edit=1
#33028 [Fbk-Opn]: mime_content_type returns inaccurate Office content types
ID: 33028 User updated by: matt at kanchi dot org Reported By: matt at kanchi dot org -Status: Feedback +Status: Open Bug Type: Filesystem function related Operating System: OS X PHP Version: 4.3.10 New Comment: Gotcha. It returns: (filename): Microsoft Office Document Previous Comments: [2005-05-13 23:33:09] [EMAIL PROTECTED] No, I meant running this command in console. [2005-05-13 22:37:18] matt at kanchi dot org Do you mean mime_content_type(file /path/to/file)? If so, that returns the error, mime_magic: invalid mode 0156130. [2005-05-13 21:37:46] [EMAIL PROTECTED] Does this work: `file /path/to/file.ppt` ? [2005-05-13 20:12:34] matt at kanchi dot org Description: Certain Office files do not return an accurate MIME content type with mime_content_type. Excel and Powerpoint, for example, return an application/msword type, while Access returns text/plain. Images, text, and Word files return correctly. These files were generated in Office 2002 for Windows. Configuration options: --with-mime-magic From php.ini: mime_magic mime_magic support = enabled Directive = Local Value = Master Value mime_magic.magicfile = /usr/share/file/magic.mime = /usr/share/file/magic.mime Reproduce code: --- mime_content_type(/some/path/to/xls-file); mime_content_type(/some/path/to/ppt-file); mime_content_type(/some/path/to/mdb-file); Expected result: application/msexcel application/mspowerpoint application/msaccess Or some variation (vnd, x-, etc.). Actual result: -- application/msword application/msword text/plain -- Edit this bug report at http://bugs.php.net/?id=33028edit=1
#32283 [Com]: zlib.output_compression = 1 but no headers sent
ID: 32283
Comment by: matt at dis dot com
Reported By: plasmahh at gmx dot net
Status: No Feedback
Bug Type: Output Control
Operating System: Linux
PHP Version: 5CVS-2005-03-14
New Comment:
I have this problem too, albeit with PHP 4.3.7. Very annoying
Previous Comments:
[2005-04-20 01:00:06] 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-04-12 08:44:22] [EMAIL PROTECTED]
Is ext/zlib compiled as shared by any chance in your system?
What was the configure line you've used?
[2005-03-25 15:13:30] plasmahh at gmx dot net
This is an example when I do it with mozilla, but its always the same
whenever an accept encoding of gzip or deflate is present...
GET / HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050321
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
[2005-03-17 18:02:21] [EMAIL PROTECTED]
What headers are being sent by the browser making the request?
[2005-03-14 19:45:02] plasmahh at gmx dot net
Does not work too with the snapshot... I have changed parts of the
php_enable_output_compression as followed, which works around my
problem...
if (php_memnstr(Z_STRVAL_PP(a_encoding), gzip, 4,
Z_STRVAL_PP(a_encoding) + Z_STRLEN_PP(a_encoding))) {
ZLIBG(compression_coding) = CODING_GZIP;
sapi_add_header(Content-Encoding: gzip,
sizeof(Content-Encoding: gzip) - 1, 1);
} else if (php_memnstr(Z_STRVAL_PP(a_encoding), deflate, 7,
Z_STRVAL_PP(a_encoding) + Z_STRLEN_PP(a_encoding))) {
ZLIBG(compression_coding) = CODING_DEFLATE;
sapi_add_header(Content-Encoding: deflate,
sizeof(Content-Encoding: deflate) - 1, 1);
} else {
return FAILURE;
}
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/32283
--
Edit this bug report at http://bugs.php.net/?id=32283edit=1
#32820 [NEW]: date_sunrise and date_sunset don't handle GMT offset well.
From: matt-dated-1114405650 dot e8a5a2 at codewalkers dot com Operating system: ALL PHP version: 5CVS-2005-04-25 (dev) PHP Bug Type: Date/time related Bug description: date_sunrise and date_sunset don't handle GMT offset well. Description: There seems to be a bug in date_sunrise and date_sunset when the GMT offset is greater than the sunrise or sunset time. For instance, if the date_sunset function returns '00:14' as the sunset time in GMT, trying to use the GMT offset of -4 would result in '-3:-4' being returned. In sunfuncs.c there is a line: ret = php_sunrise_sunset(N, latitude, longitude, zenith, calc_sunset) + gmt_offset; It seems that it should check if gmt_offset is greater than the returned value from php_sunrise_sunset and if so, add 24 to the returned value before the addition of gmt_offset. Reproduce code: --- ?php echo date(D M d Y). ', sunset time : ' .date_sunset(time(), SUNFUNCS_RET_STRING, 40, -83, 90, -4); ? Expected result: I would expect to see: Sun Apr 24 2005, sunset time : 20:14 Actual result: -- I actually see: Sun Apr 24 2005, sunset time : -3:-4 -- Edit bug report at http://bugs.php.net/?id=32820edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32820r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32820r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32820r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32820r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32820r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32820r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32820r=needscript Try newer version: http://bugs.php.net/fix.php?id=32820r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32820r=support Expected behavior: http://bugs.php.net/fix.php?id=32820r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32820r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32820r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32820r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32820r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32820r=dst IIS Stability: http://bugs.php.net/fix.php?id=32820r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32820r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32820r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32820r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32820r=mysqlcfg
#32820 [Opn]: date_sunrise and date_sunset don't handle GMT offset well.
ID: 32820 User updated by: matt-dated-1114405650 dot e8a5a2 at codewalkers Reported By: matt-dated-1114405650 dot e8a5a2 at codewalkers Status: Open Bug Type: Date/time related Operating System: ALL PHP Version: 5CVS-2005-04-25 (dev) New Comment: Sorry... There seems to be a bug in date_sunrise and date_sunset when the GMT offset is greater than the sunrise or sunset time. should have read: There seems to be a bug in date_sunrise and date_sunset when the GMT offset is negative and the absolute value is greater than the sunrise or sunset time. Previous Comments: [2005-04-25 06:24:03] matt-dated-1114405650 dot e8a5a2 at codewalkers Description: There seems to be a bug in date_sunrise and date_sunset when the GMT offset is greater than the sunrise or sunset time. For instance, if the date_sunset function returns '00:14' as the sunset time in GMT, trying to use the GMT offset of -4 would result in '-3:-4' being returned. In sunfuncs.c there is a line: ret = php_sunrise_sunset(N, latitude, longitude, zenith, calc_sunset) + gmt_offset; It seems that it should check if gmt_offset is greater than the returned value from php_sunrise_sunset and if so, add 24 to the returned value before the addition of gmt_offset. Reproduce code: --- ?php echo date(D M d Y). ', sunset time : ' .date_sunset(time(), SUNFUNCS_RET_STRING, 40, -83, 90, -4); ? Expected result: I would expect to see: Sun Apr 24 2005, sunset time : 20:14 Actual result: -- I actually see: Sun Apr 24 2005, sunset time : -3:-4 -- Edit this bug report at http://bugs.php.net/?id=32820edit=1
#31300 [Com]: ArrayAccess and __get crash when using string concat in key
ID: 31300
Comment by: matt dot bevan at marginsoftware dot com
Reported By: gardan at gmx dot com
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2005-01-10
New Comment:
Consider this bug confirmed using Apache/2.0.52
(Gentoo/Linux) PHP/5.0.3 but is not re-producible in a
small amount of code.
In my case, performing strange acts got around the bug
when using the array access more than once with three
other variable assignments in-between the first call and
second:
- The first dot-concatenated call worked fine.
- The second segfaulted Apache, unless:
- The first call is commented out, or
- The second call is placed right below the first, or
- One line of three lines is commented out.
- All array accesses are changed to use sprintf
not dot concatenation.
It doesn't matter which line of the three simple, static
variable assignments is commented.
This bug drove me crazy all today. I'm going to have
nightmares about this bug. ;)
Previous Comments:
[2005-01-11 08:24:01] [EMAIL PROTECTED]
ArrayAccess is defined and controlled by the engine not SPL
[2004-12-26 22:40:38] gardan at gmx dot com
Still crashing with cvs snapshot (Windows).
[2004-12-26 12:24:08] [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
[2004-12-26 07:32:35] Beater at orgalan dot de
I can partially confirm this for 5.0.3 running on Windows XP. The
behaviour is very unpredictable.
Following you'll find some test cases and the behaviour on my system.
class arr implements ArrayAccess {
public $x = array(ab_cd = hello);
function offsetExists($offset) { return isset($this-x[$offset]); }
function offsetSet($offset, $value) { $this-x[$offset] = $value; }
function offsetGet($offset) { return $this-x[$offset]; }
function offsetUnset($offset) { unset($this-x[$offset]); }
function __get($offset) { return $this-x[$offset]; }
}
$test = new arr;
case 1:
echo($test[ab._cd]);// crashs
case 2:
echo($test[ab_cd]); // works
echo($test[ab._cd]);// works
case 3:
echo($test[ab_cd]); // works
echo($test-{ab_cd}); // works
echo($test[ab._cd]);// crashs
sounds stupid, but you'll confirm it, i guess
[2004-12-26 07:06:45] gardan at gmx dot com
Description:
When executing the posted code, PHP 5.0.2 and 5.0.3rc-2 crash and kill
apache on the first echo. When uncommenting the first echo, it crashes
on the second one.
Like this
echo($test[ab_cd]);
echo($test-{ab_cd});
it works.
Reproduce code:
---
class arr implements ArrayAccess {
public $x = array(ab_cd = hello);
function offsetExists($offset) { return isset($this-x[$offset]); }
function offsetSet($offset, $value) { $this-x[$offset] = $value; }
function offsetGet($offset) { return $this-x[$offset]; }
function offsetUnset($offset) { unset($this-x[$offset]); }
function __get($offset) { return $this-x[$offset]; }
}
$test = new arr;
echo($test[ab_cd]); // works
echo($test-{ab_cd}); // works
echo($test[ab._cd]);// crash
echo($test-{ab._cd}); // crash
Expected result:
hellohellohellohello
Actual result:
--
hellohello crash
Windows Apache Log:
Parent: child process exited with status 3221225477 -- Restarting
--
Edit this bug report at http://bugs.php.net/?id=31300edit=1
#31487 [NEW]: Reference: http://bugs.php.net/bug.php?id=31195
From: matt at atopia dot net
Operating system: FreeBSD 4.10
PHP version: 4.3.10
PHP Bug Type: MSSQL related
Bug description: Reference: http://bugs.php.net/bug.php?id=31195
Description:
The bug described in http://bugs.php.net/bug.php?id=31195 has not been
fixed in the latest snapshot, Tuesday Jan 11, 4.11-DEV.
As a side comment, I have two identical servers ... frodo and sox. Frodo
is production, sox is devel. They have the same configuration. This
issue ONLY exists on frodo, it does not exist on sox. So it seems this
bug (if it is not fixed in CVS) is circumstancial. However, a revert back
to 4.3.9 instantly fixed the problem on frodo, so I know its an issue with
4.3.10.
Reproduce code:
---
$query = insert into my_tables (name) values ('Matt');
if (mssql_query($query))
echo Successful Query;
else
echo Unsuccessful Query;
Expected result:
the row Matt is successfully inserted into the table, but bool(false) is
returned (proved with var_dump).
Actual result:
--
bool(false) is returned where bool(true) should be returned.
--
Edit bug report at http://bugs.php.net/?id=31487edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31487r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31487r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31487r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31487r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31487r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31487r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31487r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31487r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31487r=support
Expected behavior: http://bugs.php.net/fix.php?id=31487r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31487r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31487r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31487r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31487r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31487r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31487r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31487r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31487r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31487r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31487r=mysqlcfg
#31487 [Opn-Bgs]: Reference: http://bugs.php.net/bug.php?id=31195
ID: 31487
User updated by: matt at atopia dot net
Reported By: matt at atopia dot net
-Status: Open
+Status: Bogus
Bug Type: MSSQL related
Operating System: FreeBSD 4.10
PHP Version: 4.3.10
New Comment:
Bogus on my part.
Previous Comments:
[2005-01-11 06:29:45] matt at atopia dot net
Description:
The bug described in http://bugs.php.net/bug.php?id=31195 has not been
fixed in the latest snapshot, Tuesday Jan 11, 4.11-DEV.
As a side comment, I have two identical servers ... frodo and sox.
Frodo is production, sox is devel. They have the same configuration.
This issue ONLY exists on frodo, it does not exist on sox. So it seems
this bug (if it is not fixed in CVS) is circumstancial. However, a
revert back to 4.3.9 instantly fixed the problem on frodo, so I know
its an issue with 4.3.10.
Reproduce code:
---
$query = insert into my_tables (name) values ('Matt');
if (mssql_query($query))
echo Successful Query;
else
echo Unsuccessful Query;
Expected result:
the row Matt is successfully inserted into the table, but bool(false)
is returned (proved with var_dump).
Actual result:
--
bool(false) is returned where bool(true) should be returned.
--
Edit this bug report at http://bugs.php.net/?id=31487edit=1
#29853 [Com]: Output buffering = Off is slow
ID: 29853 Comment by: matt at cloverbasin dot com Reported By: webmaster at neteject dot com Status: Open Bug Type: Performance problem Operating System: Windows 2003 PHP Version: 5.0.0 New Comment: Windows 2003 Standard, IIS6.0, PHP 4.3.2, PHP4ISAPI.dll PHP page rendering is excrutiatingly slow, static HTML pages still render quickly. CGI/PHP.exe does not seem to exhibit this behavior. The Output Buffering = On workaround seemed to be succesful. Previous Comments: [2004-09-02 19:30:29] php at sharpdreams dot com I also experienced this, and yes it is an IIS issue. AFAIK, output buffering is the only solution. You can do your own output buffering in the page if certain blocks need to be pushed to the client (ie, in long calculations). [2004-08-26 17:50:00] webmaster at neteject dot com Description: PHP 5.0.1 ISAPI Windows 2003 Enterprise Server. I have tested this on different machines with W2003 Server Enterprise installed. I have webppages with a lot of phpchunks with sql and different calculations. When have outbuffering to off the page is printed very slow and halts in almost every chunk. Setting the output to On prints the page fast. I have tested this on my local network. I have connected to 1 xp machine and 2 w2003 machines. XP did not have any problems with output buffering off. One interesting thing is that the page runs quite fast on the local computer which makes me wonder if it has any conjunction with how IIS 6 works. Anyway, the fact still remains that running with output buffering on produces a fast page from anywhere. Reproduce code: --- ? Try any mysql_query here. ? HTML BODY ? Try any mysql_query here. ? TABLE ? Try any mysql_query here. ? etc... Expected result: Page loading in chunks -- Edit this bug report at http://bugs.php.net/?id=29853edit=1
#29426 [Com]: Incomplete/inconsistent functionality
ID: 29426 Comment by: matt dot bevan at marginsoftware dot com Reported By: php at peterrobins dot co dot uk Status: Open Bug Type: SimpleXML related Operating System: Linux 2.4 PHP Version: 5.0.0 New Comment: I am also in the position where I need to be able to create and insert a SimpleXMLElement before or after an arbitrary SimpleXMLElement, then remove the previous instance. This is to move XML elements from one location in an XML file into another. I'll likely be switching to/from a DOM object to accomplish this, however. Previous Comments: [2004-09-19 17:40:18] phpbugs at ilibi dot com Either the documentation for simplexml should be clarified about exactly what can and can not be added/ edited. Or the ability to add nodes should be added to simplexml. [2004-08-08 01:18:36] cyberlot at cyberlot dot net Confirming this bug exists, Have the same problem, I need to add to a simplexml object on the fly and can't [2004-07-28 13:22:59] php at peterrobins dot co dot uk Description: According to the manual page, you can add a node with SimpleXML, but this does not seem to work, either as $xml-movie[0]-characters[0]-character[0]-age = '21'; nor as $xml-movie[0]-rating[2] = 'not bad'; Deletion works on attributes unset($xml-movie[0]-rating[1]['type']); but at node level, deletes all unset($xml-movie[0]-rating); This is inconsistent with reading where $xml-movie[0]-rating fetches the first node only. unset($xml-movie-rating); deletes all ratings for the 1st movie only. It does not appear possible to delete just 1 node unset($xml-movie[0]-rating[1]); Because objs are now refs not copies, can do this $rat = $xml-movie[0]-rating[0]; $rat['name'] = 'judge'; but not this $rat = 'new content'; nor this $rat-child[0] = 'new rating'; and if I try and do $rat-child = 'new rating'; I get 'Attempt to assign property of non-object' -- Edit this bug report at http://bugs.php.net/?id=29426edit=1
#28007 [Com]: FreeTDS support will not compile
ID: 28007 Comment by: matt at atopia dot net Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: MSSQL related Operating System: Linux PHP Version: 4.3.6RC3 Assigned To: fmk New Comment: This still seems to be an issue with php-4.3.8. Is the patch shown in this report reliable? In file included from /usr/archive/source/php-4.3.8/ext/mssql/php_mssql.c:33: /usr/archive/source/php-4.3.8/ext/mssql/php_mssql.h:41: redefinition of `SHORT' /usr/local/include/sybdb.h:117: `SHORT' previously declared here *** Error code 1 Stop in /usr/archive/source/php-4.3.8. Previous Comments: [2004-04-21 01:36:12] [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. Older versions of FreeTDS does not define the SHORT type. [2004-04-15 19:18:12] [EMAIL PROTECTED] Assigned to Frank who added the line in question in rev 1.84 of php_mssql.c [2004-04-15 10:27:22] [EMAIL PROTECTED] Description: See bug #21544 -- I was asked to open a new report. ./configure --with-mssql ... works, but a make of the same fails with: (see actual result). FreeTDS version: (debian unstable) 0.53-7 Sniper mentioned that he thinks it's my FreeTDS install. Could be. The attached patch seems to completely fix the problem, though. As mentioned in the other bug: I'm not a C guy, so I could be way wrong on this. All I know is that after patching, --with-mssql compiles and the library seems to work (as) well (as mssql on linux has ever worked). S --- Index: ext/mssql/php_mssql.c === RCS file: /repository/php-src/ext/mssql/php_mssql.c,v retrieving revision 1.86.2.31 diff -u -r1.86.2.31 php_mssql.c --- ext/mssql/php_mssql.c 30 Mar 2004 17:54:38 - 1.86.2.31 +++ ext/mssql/php_mssql.c 14 Apr 2004 15:18:18 - @@ -336,7 +336,7 @@ dbsetlogintime(MS_SQL_G(connect_timeout)); if (MS_SQL_G(timeout) 0) MS_SQL_G(timeout) = 60; dbsettime(MS_SQL_G(timeout)); - dbsetmaxprocs((SHORT)MS_SQL_G(max_procs)); + dbsetmaxprocs((int)MS_SQL_G(max_procs)); return SUCCESS; } Reproduce code: --- n/a Expected result: compile Actual result: -- ext/mssql/php_mssql.c: In function `zm_activate_mssql': ext/mssql/php_mssql.c:339: `SHORT' undeclared (first use in this function) ext/mssql/php_mssql.c:339: (Each undeclared identifier is reported only once ext/mssql/php_mssql.c:339: for each function it appears in.) make: *** [ext/mssql/php_mssql.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=28007edit=1
#28867 [Bgs]: Variables not being passed on form post
ID: 28867 User updated by: matt at atopia dot net Reported By: matt at atopia dot net Status: Bogus Bug Type: HTTP related Operating System: FreeBSD 4.10 PHP Version: 4.3.7 New Comment: Did you try copying those scripts i posted to your own server and running them? Cause I just copied them to another server with different config and its still occuring :-( Previous Comments: [2004-07-08 11:54:18] [EMAIL PROTECTED] Looks like it's either: a) configuration mistake done by you. b) Some bug in Apache when you configure it some weird way. (not PHP bug as I can't reproduce this either on my own machine, but it's Linux where everything usually works anyway :) [2004-07-06 16:55:42] matt at atopia dot net Please check out the source of my test case (has been included in the original post). [2004-07-06 16:54:39] matt at atopia dot net I just tested using Internet Explorer 6 and Mozilla Firefox .9 problem exists in both. Tried on 10 different computers as well (I'm in a lab). -Matt [2004-07-06 15:53:43] [EMAIL PROTECTED] I can't reproduce either. Does this happen with ANY browser? (something else than Mozilla, like IE..:) [2004-06-25 16:25:32] matt at atopia dot net PHP Info At: http://www.atopia.net/test/mozbug215479/displayinfo25472358158709325.php user/pass: test/test php.ini is same as php-dist.ini in the source. 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/28867 -- Edit this bug report at http://bugs.php.net/?id=28867edit=1
#28867 [Fbk-Opn]: Variables not being passed on form post
ID: 28867 User updated by: matt at atopia dot net Reported By: matt at atopia dot net -Status: Feedback +Status: Open Bug Type: HTTP related Operating System: FreeBSD 4.10 PHP Version: 4.3.7 New Comment: I just tested using Internet Explorer 6 and Mozilla Firefox .9 problem exists in both. Tried on 10 different computers as well (I'm in a lab). -Matt Previous Comments: [2004-07-06 15:53:43] [EMAIL PROTECTED] I can't reproduce either. Does this happen with ANY browser? (something else than Mozilla, like IE..:) [2004-06-25 16:25:32] matt at atopia dot net PHP Info At: http://www.atopia.net/test/mozbug215479/displayinfo25472358158709325.php user/pass: test/test php.ini is same as php-dist.ini in the source. [2004-06-25 16:07:49] [EMAIL PROTECTED] I have just tested this and the bug cannot be reproduced on Linux with nearly the same configuration. Could you please append phpinfo() at the end of step2.php so that we can have a look at possible configuration differences. Also plase post your php.ini on your site. [2004-06-21 16:12:24] matt at atopia dot net Description: This was originally posted as a mozilla firefox bug, and left open for a good 9 months until today... http://bugzilla.mozilla.org/show_bug.cgi?id=215479 Seems it has been described as a bug in PHP... Originally, the problem I was experiencing last September was the following: After HTTP authentication, both variables (PHP_AUTH_USER and REMOTE_USER) would be set until I submitted a form that used method=post. After that, neither variable would be set until I visited a page using GET (not post). Then, both variables would reset themselves (I assume because the browser posts the username/pass each request with HTTP authentication). Originally, the problem occured with HTTP and HTTPS, so I have setup two different test cases. As of now, I am currently experiencing this problem still, but only with the REMOTE_USER variable. A new version of PHP seems to have fixed the PHP_AUTH_USER problem. (this will all be shown in the test case). Reproduce code: --- http://www.atopia.net/test/mozbug215479/step1.php https://secure.webaries.com/atopia/test/mozbug215479/step1.php User/Pass: test/test Source code is available for both of the files by replacing .php with .source -- Edit this bug report at http://bugs.php.net/?id=28867edit=1
#28867 [Opn]: Variables not being passed on form post
ID: 28867 User updated by: matt at atopia dot net Reported By: matt at atopia dot net Status: Open Bug Type: HTTP related Operating System: FreeBSD 4.10 PHP Version: 4.3.7 New Comment: Please check out the source of my test case (has been included in the original post). Previous Comments: [2004-07-06 16:54:39] matt at atopia dot net I just tested using Internet Explorer 6 and Mozilla Firefox .9 problem exists in both. Tried on 10 different computers as well (I'm in a lab). -Matt [2004-07-06 15:53:43] [EMAIL PROTECTED] I can't reproduce either. Does this happen with ANY browser? (something else than Mozilla, like IE..:) [2004-06-25 16:25:32] matt at atopia dot net PHP Info At: http://www.atopia.net/test/mozbug215479/displayinfo25472358158709325.php user/pass: test/test php.ini is same as php-dist.ini in the source. [2004-06-25 16:07:49] [EMAIL PROTECTED] I have just tested this and the bug cannot be reproduced on Linux with nearly the same configuration. Could you please append phpinfo() at the end of step2.php so that we can have a look at possible configuration differences. Also plase post your php.ini on your site. [2004-06-21 16:12:24] matt at atopia dot net Description: This was originally posted as a mozilla firefox bug, and left open for a good 9 months until today... http://bugzilla.mozilla.org/show_bug.cgi?id=215479 Seems it has been described as a bug in PHP... Originally, the problem I was experiencing last September was the following: After HTTP authentication, both variables (PHP_AUTH_USER and REMOTE_USER) would be set until I submitted a form that used method=post. After that, neither variable would be set until I visited a page using GET (not post). Then, both variables would reset themselves (I assume because the browser posts the username/pass each request with HTTP authentication). Originally, the problem occured with HTTP and HTTPS, so I have setup two different test cases. As of now, I am currently experiencing this problem still, but only with the REMOTE_USER variable. A new version of PHP seems to have fixed the PHP_AUTH_USER problem. (this will all be shown in the test case). Reproduce code: --- http://www.atopia.net/test/mozbug215479/step1.php https://secure.webaries.com/atopia/test/mozbug215479/step1.php User/Pass: test/test Source code is available for both of the files by replacing .php with .source -- Edit this bug report at http://bugs.php.net/?id=28867edit=1
#28867 [Fbk-Opn]: Variables not being passed on form post
ID: 28867 User updated by: matt at atopia dot net Reported By: matt at atopia dot net -Status: Feedback +Status: Open Bug Type: Variables related Operating System: FreeBSD 4.10 PHP Version: 4.3.7 New Comment: PHP Info At: http://www.atopia.net/test/mozbug215479/displayinfo25472358158709325.php user/pass: test/test php.ini is same as php-dist.ini in the source. Previous Comments: [2004-06-25 16:07:49] [EMAIL PROTECTED] I have just tested this and the bug cannot be reproduced on Linux with nearly the same configuration. Could you please append phpinfo() at the end of step2.php so that we can have a look at possible configuration differences. Also plase post your php.ini on your site. [2004-06-21 16:12:24] matt at atopia dot net Description: This was originally posted as a mozilla firefox bug, and left open for a good 9 months until today... http://bugzilla.mozilla.org/show_bug.cgi?id=215479 Seems it has been described as a bug in PHP... Originally, the problem I was experiencing last September was the following: After HTTP authentication, both variables (PHP_AUTH_USER and REMOTE_USER) would be set until I submitted a form that used method=post. After that, neither variable would be set until I visited a page using GET (not post). Then, both variables would reset themselves (I assume because the browser posts the username/pass each request with HTTP authentication). Originally, the problem occured with HTTP and HTTPS, so I have setup two different test cases. As of now, I am currently experiencing this problem still, but only with the REMOTE_USER variable. A new version of PHP seems to have fixed the PHP_AUTH_USER problem. (this will all be shown in the test case). Reproduce code: --- http://www.atopia.net/test/mozbug215479/step1.php https://secure.webaries.com/atopia/test/mozbug215479/step1.php User/Pass: test/test Source code is available for both of the files by replacing .php with .source -- Edit this bug report at http://bugs.php.net/?id=28867edit=1
#28626 [NEW]: mssql, redefinition of `SHORT' compiler error
From: matt at iws dot co dot nz Operating system: Redhat 7.1 PHP version: 4.3.7 PHP Bug Type: Compile Failure Bug description: mssql, redefinition of `SHORT' compiler error Description: When compiling php against freetds I get the following error: In file included from /root/setup/php-4.3.7/ext/mssql/php_mssql.c:33: /root/setup/php-4.3.7/ext/mssql/php_mssql.h:41: redefinition of `SHORT' /usr/local/freetds/include/sybdb.h:103: `SHORT' previously declared here make: *** [ext/mssql/php_mssql.lo] Error 1 PHP version: 4.3.7 FreeTDS version: 0.61 Configure: ./configure --with-mysql=/usr/local/mysql --with-pgsql --enable-sockets --with-gd --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-freetype-dir=/usr/local/lib --with-zlib-dir=/usr/lib --with-pdflib --with-pspell --with-apxs=/usr/local/apache/bin/apxs --with-xmlrpc --with-xml --with-mssql=/usr/local/freetds/ --with-curl --enable-sysvshm --enable-sysvsem --enable-sysvmsg --enable-shmop --enable-ftp --with-imap=/usr/local/imap-2000e --enable-dbase --with-openssl=/usr/local/ssl/ php version 4.3.6 works fine with the same configuration. I presume the error is caused by the latest update to the mssql extention to fix compile errors with older versions of freeTDS. -- Edit bug report at http://bugs.php.net/?id=28626edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28626r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28626r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28626r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28626r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28626r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28626r=needscript Try newer version: http://bugs.php.net/fix.php?id=28626r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28626r=support Expected behavior: http://bugs.php.net/fix.php?id=28626r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28626r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28626r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28626r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28626r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28626r=dst IIS Stability: http://bugs.php.net/fix.php?id=28626r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28626r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28626r=float
#26187 [NEW]: mysql_num_rows returns error when empty instead of 0
From: matt at 1lsn dot com Operating system: Slackware 8.1 PHP version: 4.3.4 PHP Bug Type: MySQL related Bug description: mysql_num_rows returns error when empty instead of 0 Description: when doing a mysql_num_rows, if there are no matching rows it gives an error instead of returning 0. Reproduce code: --- $Query = SELECT * FROM MyTable WHERE Field1 = '1' and Field2 = '2' ; $Result = mysql_query($Query) or die(Error101: . mysql_error().BR.$Query); $CNT = mysql_num_rows($Result) OR DIE(Error 102: .BR.mysql_error().BR.$Query.BR); echo There are .$CNT. matching results. ; Expected result: $CNT should be set to '0' and page should display There are 0 matching results. Actual result: -- Error 102: SELECT * FROM MyTable WHERE Field1 = '1' and Field2 = '2' -- Edit bug report at http://bugs.php.net/?id=26187edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26187r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26187r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26187r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26187r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26187r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26187r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26187r=support Expected behavior: http://bugs.php.net/fix.php?id=26187r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26187r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26187r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26187r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26187r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26187r=dst IIS Stability: http://bugs.php.net/fix.php?id=26187r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26187r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26187r=float
#23929 [Com]: strange register_shutdown_function error for undefined functions
ID: 23929
Comment by: matt at matts dot org
Reported By: philip at cornado dot com
Status: Bogus
Bug Type:*General Issues
PHP Version: 4.3.2
Assigned To: helly
New Comment:
Philip is right, it's a stupid and cryptic error message.
The error returned should be useful at least.
Bad call.
Previous Comments:
[2003-06-01 12:11:44] [EMAIL PROTECTED]
I'm sorry, I didn't realize that Unknown() and line #0 were official,
I'll add this to the documentation.
[2003-06-01 10:44:56] [EMAIL PROTECTED]
No bug here. Philip, ask such questions on the mailing list and stop
spamming the bug system with these..
[2003-05-31 21:15:03] [EMAIL PROTECTED]
I don't understand the answer, and this is certainly not documented.
Also, why did you assign it to yourself and mark it as bogus?
[2003-05-31 17:00:26] [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
When some engine facility tries to call a non existing functions you
receive such errors.
[2003-05-31 15:55:47] philip at cornado dot com
register_shutdown_function() provides a warning instead of a fatal
error when calling an undefined function. Not sure if this is
intentional or not but here's a test script:
?php
echo 'hello';
register_shutdown_function('do_not_exist');
?
And next, the strange looking error. Same result for both Apache
module and CLI:
Hello
Warning: Unknown(): Unable to call do_not_exist() - function does not
exist in Unknown on line 0
A PHP5 CLI demonstrates this same error.
--
Edit this bug report at http://bugs.php.net/?id=23929edit=1
#25428 [Com]: xmlrpc_server_call_method() causes segfault
ID: 25428 Comment by: matt dot flaherty at nextgem dot com Reported By: mfladischer at gmx dot net Status: Open Bug Type: XMLRPC-EPI related Operating System: RedHat 9 PHP Version: 5CVS-2003-09-08 (dev) New Comment: Same problem using PHP 4.3.3 (Latest stable) running as a shared module under Apache 2.0.47 in prefork mode on RedHat 8.0. Here is my config line: ./configure --with-apxs2=/home/gemmgr/httpd/bin/apxs --with-mysql --with-xml -with-dom --with-expat --with-sablot --with-zlib --with-zend --with-curl --with-openssl --with-xmlrpc --with-iconv I think some of the options may be meaningless but it did configure and build fine. Previous Comments: [2003-09-08 03:38:40] mfladischer at gmx dot net Description: When i'm trying to run a XML-RPC server (using the xml-rpc-extension) with PHP5 i get a segfault. Reproduce code: --- ?php $request = xmlrpc_encode_request(system.listMethods, array()); $server = xmlrpc_server_create(); echo xmlrpc_server_call_method($server, $request, false); ? Expected result: ?xml version=1.0 encoding=iso-8859-1? methodResponse params param value array data value stringsystem.listMethods/string /value value stringsystem.methodHelp/string /value value stringsystem.methodSignature/string /value value stringsystem.describeMethods/string /value value stringsystem.multiCall/string /value value stringsystem.getCapabilities/string /value /data /array /value /param /params /methodResponse Actual result: -- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 19945)] 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 1033set_output_options(out, *output_opts); (gdb) bt #0 0x0822d92f in zif_xmlrpc_server_call_method (ht=3, return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1) at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033 #1 0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541 #2 0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180, op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687 #3 0x0829e834 in execute (op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:1267 #4 0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /linux/devel/php5/Zend/zend.c:1018 #5 0x0823f15c in php_execute_script (primary_file=0xb580) at /linux/devel/php5/main/main.c:1625 #6 0x082acea7 in main (argc=2, argv=0xb614) at /linux/devel/php5/sapi/cli/php_cli.c:910 #7 0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=25428edit=1
#25628 [NEW]: Cannot Connect to postgres database
From: matt at coffeecup dot com Operating system: Red Hat Enterprise Linux ES 2.1 PHP version: 4.3.3 PHP Bug Type: PostgreSQL related Bug description: Cannot Connect to postgres database Description: I upgraded to php 4.3.3, and started receiving this error when connecting to postgres: PHP Warning: pg_connect(): Cannot create new link. Too many open links (0). I use the same configure line with php 4.3.2: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-curl --with-xml --with-mysql=/usr --with-ssl --with-mcrypt --enable-xslt-sablot --with-gd --with-jpeg-dir=/usr/bin/cjpeg --with-zlib --with-ttf --with-pgsql php.ini file remains the same: ; Maximum number of links (persistent+non persistent). -1 means no limit. pgsql.max_links = -1 When I re-install 4.3.2, the problem goes away. Reproduce code: --- $bd_db = pg_connect (host=$hostname dbname=$database_name user=$username password=$password); Expected result: A connection to the database given Actual result: -- PHP Warning: pg_connect(): Cannot create new link. Too many open links (0). -- Edit bug report at http://bugs.php.net/?id=25628edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25628r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25628r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25628r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25628r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25628r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25628r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25628r=support Expected behavior: http://bugs.php.net/fix.php?id=25628r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25628r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25628r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25628r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25628r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25628r=dst IIS Stability: http://bugs.php.net/fix.php?id=25628r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25628r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25628r=float
#25628 [Fbk-Opn]: Cannot Connect to postgres database
ID: 25628 User updated by: matt at coffeecup dot com Reported By: matt at coffeecup dot com -Status: Feedback +Status: Open Bug Type: PostgreSQL related Operating System: Red Hat Enterprise Linux ES 2.1 PHP Version: 4.3.3 New Comment: This version had the exact same problem. Previous Comments: [2003-09-22 12:23:20] [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-09-22 11:58:16] matt at coffeecup dot com Description: I upgraded to php 4.3.3, and started receiving this error when connecting to postgres: PHP Warning: pg_connect(): Cannot create new link. Too many open links (0). I use the same configure line with php 4.3.2: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-curl --with-xml --with-mysql=/usr --with-ssl --with-mcrypt --enable-xslt-sablot --with-gd --with-jpeg-dir=/usr/bin/cjpeg --with-zlib --with-ttf --with-pgsql php.ini file remains the same: ; Maximum number of links (persistent+non persistent). -1 means no limit. pgsql.max_links = -1 When I re-install 4.3.2, the problem goes away. Reproduce code: --- $bd_db = pg_connect (host=$hostname dbname=$database_name user=$username password=$password); Expected result: A connection to the database given Actual result: -- PHP Warning: pg_connect(): Cannot create new link. Too many open links (0). -- Edit this bug report at http://bugs.php.net/?id=25628edit=1
