#41480 [Opn->Bgs]: realpath returns false on valid path without filename
ID: 41480 Updated by: [EMAIL PROTECTED] Reported By: derek dot ethier at gmail dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Windows Server 2003 PHP Version: 5.2.2 New Comment: 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 The current behavior is the expected one. Previous Comments: [2007-05-24 02:13:56] derek dot ethier at gmail dot com Description: In PHP < 5.2.2 the realpath function would return a string value on a valid path passed to the function. In 5.2.2 it returns false unless a filename is specified. Going over the documentation it looks like this might be an expected result, but it is different from earlier versions. Extensions: curl, ldap, mssql, mysql, pdo, pdo_sqlite, pdo_mssql, sqlite, tidy, ssh2 I'm using the php.ini file from my 5.2.1 installation and going over the incompatibilities and changes from 5.2.1 the only change that seems related is this one: - SplFileObject::getFilename() returns the filename, not relative/path/to/file, as of PHP 5.2.1. Reproduce code: --- $path1 = 'E:\\webroot\\'; $path2 = 'E:\\webroot\\index.php'; var_dump(realpath($path1)); var_dump(realpath($path2)); Expected result: string 'E:\webroot\' (length=11) string 'E:\webroot\index.php' (length=20) Actual result: -- boolean false string 'E:\webroot\index.php' (length=20) -- Edit this bug report at http://bugs.php.net/?id=41480&edit=1
#35691 [Com]: Can't change to another drive letter using chdir()
ID: 35691 Comment by: laifanleuk at net-yan dot com Reported By: ejwaibel at gmail dot com Status: Assigned Bug Type: Directory function related Operating System: Windows PHP Version: 5CVS-2005-12-19 (snap) Assigned To: nlopess New Comment: Same problem here. Try to open_dir to a SUBST'ed directory failed. Using XP sp2, Apache 2.2.4 is install by my admin, running as service . I have no administrator access right. Before my admin installed Apache as service, I was using apache as normal user, running in console mode. It worked perfectly then. Previous Comments: [2006-11-01 15:11:45] [EMAIL PROTECTED] I reproduce this with both Windows XP and 2003. [2006-11-01 15:05:44] [EMAIL PROTECTED] OK, I was able to reproduce the problem. I used Apache 2.0 and is_dir() doesn't work with network mapped drives. other drives work and in CLI mode it also works. (it can be because Apache runs as another user, although I haven't looked further into the problem) [2006-09-26 15:28:47] thiagomp at gmail dot com The problem appeared here with the following configuration: Windows XP SP2 PHP 5.0.5 (with Apache 1.3.33) and 5.1.6 (with Apache 2.0.59) [2006-01-20 10:18:32] jarek at katnik dot pl It happpens also with Apache 1.3.31. [2006-01-19 17:00:11] [EMAIL PROTECTED] OK, so here I go again. bug #36088 states this only happens with Apache (2.0.x) and works in CLI. Previously I had only tested in CLI, so back to testing. 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/35691 -- Edit this bug report at http://bugs.php.net/?id=35691&edit=1
#41481 [Bgs]: Execute a string as PHP code
ID: 41481 User updated by: hachque at gmail dot com Reported By: hachque at gmail dot com Status: Bogus Bug Type:Feature/Change Request PHP Version: 5.2.2 New Comment: Thanks for that. Previous Comments: [2007-05-24 07:14:32] [EMAIL PROTECTED] Please read the documentation and look for eval... [2007-05-24 06:58:49] hachque at gmail dot com Description: A function which will execute a string as PHP code. It should act exactly like include, except take a string argument instead of a file. E.g. php_exec(string $code) -- Edit this bug report at http://bugs.php.net/?id=41481&edit=1
#41497 [Fbk]: php.ini not loaded
ID: 41497 Updated by: [EMAIL PROTECTED] Reported By: dbjh at gmx dot net Status: Feedback Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: Just tested latest 5.2 snapshot on a rhel4 machine and it worked just fine using exactly same ini config options as you pasted here. Are you sure this isn't some SELinux issue? Do you get any errors in /var/log/messages ?? Can you reproduce this with CLI ? Previous Comments: [2007-05-25 23:05:52] [EMAIL PROTECTED] 1) My reply was perfectly appropriate, you did not mention what configure line you had used nor that it worked in 5.2.0. 2) What exactly is said in phpinfo() output about what php.ini is loaded when you have it in /etc ? [2007-05-25 19:30:45] dbjh at gmx dot net Last message before I start looking at source code. On both Fedora Core 4 and Red Hat Enterprise Linux (4 & 5) I used the configure options '--with-config-file-path=/etc' and '--with-config-file-scan-dir=/etc/php.d'. [2007-05-25 19:18:14] dbjh at gmx dot net I should add that PHP 5.2.0 worked without problems on Fedora Core 4. I just compiled PHP 5.2.2 on Fedora Core 4 and there the problem doesn't show up. [2007-05-25 18:09:33] dbjh at gmx dot net Please read the description before closing the bug report. I've used the same options in combination with PHP 5.2.0. No problem whatsoever. So, your answer is completely inappropriate. [2007-05-25 17:34:47] [EMAIL PROTECTED] You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) 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/41497 -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41497 [Opn->Fbk]: php.ini not loaded
ID: 41497 Updated by: [EMAIL PROTECTED] Reported By: dbjh at gmx dot net -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: 1) My reply was perfectly appropriate, you did not mention what configure line you had used nor that it worked in 5.2.0. 2) What exactly is said in phpinfo() output about what php.ini is loaded when you have it in /etc ? Previous Comments: [2007-05-25 19:30:45] dbjh at gmx dot net Last message before I start looking at source code. On both Fedora Core 4 and Red Hat Enterprise Linux (4 & 5) I used the configure options '--with-config-file-path=/etc' and '--with-config-file-scan-dir=/etc/php.d'. [2007-05-25 19:18:14] dbjh at gmx dot net I should add that PHP 5.2.0 worked without problems on Fedora Core 4. I just compiled PHP 5.2.2 on Fedora Core 4 and there the problem doesn't show up. [2007-05-25 18:09:33] dbjh at gmx dot net Please read the description before closing the bug report. I've used the same options in combination with PHP 5.2.0. No problem whatsoever. So, your answer is completely inappropriate. [2007-05-25 17:34:47] [EMAIL PROTECTED] You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) [2007-05-25 13:25:45] dbjh at gmx dot net The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). 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/41497 -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41503 [NEW]: Possible threading issue in cli
From: bryan at emarengo dot com Operating system: XP Pro sp2 PHP version: 5.2.2 PHP Bug Type: CGI related Bug description: Possible threading issue in cli Description: Stopping a script in cli via "cntl c" produces error. XP Pro sp2 php 5.2.2 apache 2.2.4 Reproduce code: --- Execute the following from a command line and press "cntl c" before it terminates naturally. Expected result: Script termination without error. Actual result: -- Error in my_thread_global_end(): 1 threads didn't exit -- Edit bug report at http://bugs.php.net/?id=41503&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41503&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41503&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41503&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41503&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41503&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41503&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41503&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41503&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41503&r=support Expected behavior:http://bugs.php.net/fix.php?id=41503&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41503&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41503&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41503&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41503&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41503&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41503&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41503&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41503&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41503&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41503&r=mysqlcfg
#33595 [Com]: recursive references leak memory
ID: 33595
Comment by: wckits at rit dot edu
Reported By: rodricg at sellingsource dot com
Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 6CVS-2005-08-02
Assigned To: dmitry
New Comment:
Any suggestion to call the destructor explicitly is misguided at best
and dangerous at worst. You may have another reference to that object
somewhere, and it will end up being a reference to a destructed object.
Previous Comments:
[2007-01-24 13:53:46] taneli at crasman dot fi
It shouldn't be a known "got cha".
I just wrote a backgrounded daemon using PHP and I had to instate a
checker process just to restart the process any time it dies (because it
leaks memory about 30 megs per "daemon loop", because of references).
[2006-11-02 22:28:05] judas dot iscariote at gmail dot com
taneli at crasman dot fi :
- This is a well known "gotcha" see [1]
- for the gory details, please see [2], this is not "that easy" to
fix.
1.
http://en.wikipedia.org/wiki/Reference_counting#Advantages_and_disadvantages
2. ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
[2006-11-01 09:07:48] taneli at crasman dot fi
Please address this bug, it's very short-sighted to rely on the fact
that memory is freed on shutdown (especially when your either your box
starts trashing or memory_limit kicks in and fails your request because
of a bug in the interpreter).
[2006-08-15 12:02:00] ruslan dot kyrychuk at gmail dot com
Maybe solutution can be to call destructor every time when new object
is assigned to old reference?
Example:
b = new B($this);
}
function __destruct () {
$this->b->__destruct();
}
}
class B {
function __construct ($parent = NULL) {
$this->parent = $parent;
}
function __destruct () {
unset($this->parent);
}
}
for ($i = 0 ; $i < 100 ; $i++) {
$a = new A();
$a->__destruct();
}
echo number_format(memory_get_usage());
?>
$a->__destruct(); can be called automatically because new reference is
created. Then writing correct destructors will solve this issue.
Or maybe I missing something?
[2006-05-04 14:08:22] frode at coretrek dot com
I worked around this exact problem by using a proxy class with a
destructor that explicitly breaks the cycle; I got the idea from a
perl.com[1] article describing how perl suffers from the same problem.
It's also interesting to note that perl has chosen a different (less
elegant) solution to the problem than python, by introducing weak
references.
[1] http://www.perl.com/pub/a/2002/08/07/proxyobject.html
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/33595
--
Edit this bug report at http://bugs.php.net/?id=33595&edit=1
#41479 [Opn->Csd]: Memory Leaks when creating a DOMDocument
ID: 41479 User updated by: cmmtch at rit dot edu Reported By: cmmtch at rit dot edu -Status: Open +Status: Closed Bug Type: DOM XML related Operating System: SunOS 5.10 sparc PHP Version: 5.2.2 New Comment: This was actually do to xdebug Previous Comments: [2007-05-23 21:11:51] cmmtch at rit dot edu Description: Every time you create a new DOMDocument, even if you unset it directly afterwards, a small amount of memory is leaked. Reproduce code: --- Expected result: Check the memory usage after a few seconds and notice it will go up dramatically. Actual result: -- When checking how much memory is used by this process, it will go up with time, even though no variables are being left unset. This means that every time a new DOMDocument is constructed, it allocates more memory than it's destructor is handling. This can be very bad when creating lots of DOMDocuments within a single process. -- Edit this bug report at http://bugs.php.net/?id=41479&edit=1
#41501 [Opn]: crash on date test 009.phpt
ID: 41501
Updated by: [EMAIL PROTECTED]
Reported By: stas at zend dot com
Status: Open
Bug Type: Date/time related
Operating System: Windows XP
PHP Version: 5.2.3RC1
New Comment:
Looks like it happens because Windows strftime doesn't understand many
of the formats Unix one does _and_ on MSVC8 it is configured by default
to throw an error (leading to DrWatson dialog) when invalid parameters
are used.
Previous Comments:
[2007-05-25 18:02:20] stas at zend dot com
Description:
php build 5.2.3rc1 crashes on date/tests/009.phpt on Windows.
The line leading to the crash seems to be this one:
var_dump(strftime("%a %A %b %B %c %C %d %D %e %g %G %h %H %I %j %m %M
%n %p %r %R %S %t %T %u %U %V %W %w %x %X %y %Y %Z %z %%", $t));
--
Edit this bug report at http://bugs.php.net/?id=41501&edit=1
#41497 [Opn]: php.ini not loaded
ID: 41497 User updated by: dbjh at gmx dot net Reported By: dbjh at gmx dot net Status: Open Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: I should add that PHP 5.2.0 worked without problems on Fedora Core 4. I just compiled PHP 5.2.2 on Fedora Core 4 and there the problem doesn't show up. Previous Comments: [2007-05-25 18:09:33] dbjh at gmx dot net Please read the description before closing the bug report. I've used the same options in combination with PHP 5.2.0. No problem whatsoever. So, your answer is completely inappropriate. [2007-05-25 17:34:47] [EMAIL PROTECTED] You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) [2007-05-25 13:25:45] dbjh at gmx dot net The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). [2007-05-25 11:46:51] dbjh at gmx dot net Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41502 [NEW]: getColumnMeta() table name support for pdo_sqlite
From: Antti dot Andreimann at mail dot ee Operating system: all PHP version: 5CVS-2007-05-25 (snap) PHP Bug Type: Feature/Change Request Bug description: getColumnMeta() table name support for pdo_sqlite Description: During the processing of FR #41416 PDO->getColumnMeta was enhanced so, that it will return table names for mysql result columns. Since this is a useful feature for other DBMS's as well I have created a patch that will implement this feature in pdo_sqlite. http://www.linux.ee/~anttix/php-pdo_sqlite-tablenames.patch Please consider committing. -- Edit bug report at http://bugs.php.net/?id=41502&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41502&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41502&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41502&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41502&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41502&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41502&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41502&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41502&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41502&r=support Expected behavior:http://bugs.php.net/fix.php?id=41502&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41502&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41502&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41502&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41502&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41502&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41502&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41502&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41502&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41502&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41502&r=mysqlcfg
#41497 [Opn]: php.ini not loaded
ID: 41497 User updated by: dbjh at gmx dot net Reported By: dbjh at gmx dot net Status: Open Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: Last message before I start looking at source code. On both Fedora Core 4 and Red Hat Enterprise Linux (4 & 5) I used the configure options '--with-config-file-path=/etc' and '--with-config-file-scan-dir=/etc/php.d'. Previous Comments: [2007-05-25 19:18:14] dbjh at gmx dot net I should add that PHP 5.2.0 worked without problems on Fedora Core 4. I just compiled PHP 5.2.2 on Fedora Core 4 and there the problem doesn't show up. [2007-05-25 18:09:33] dbjh at gmx dot net Please read the description before closing the bug report. I've used the same options in combination with PHP 5.2.0. No problem whatsoever. So, your answer is completely inappropriate. [2007-05-25 17:34:47] [EMAIL PROTECTED] You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) [2007-05-25 13:25:45] dbjh at gmx dot net The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). [2007-05-25 11:46:51] dbjh at gmx dot net Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41497 [Bgs->Opn]: php.ini not loaded
ID: 41497 User updated by: dbjh at gmx dot net Reported By: dbjh at gmx dot net -Status: Bogus +Status: Open Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: Please read the description before closing the bug report. I've used the same options in combination with PHP 5.2.0. No problem whatsoever. So, your answer is completely inappropriate. Previous Comments: [2007-05-25 17:34:47] [EMAIL PROTECTED] You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) [2007-05-25 13:25:45] dbjh at gmx dot net The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). [2007-05-25 11:46:51] dbjh at gmx dot net Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41501 [NEW]: crash on date test 009.phpt
From: stas at zend dot com
Operating system: Windows XP
PHP version: 5.2.3RC1
PHP Bug Type: Date/time related
Bug description: crash on date test 009.phpt
Description:
php build 5.2.3rc1 crashes on date/tests/009.phpt on Windows.
The line leading to the crash seems to be this one:
var_dump(strftime("%a %A %b %B %c %C %d %D %e %g %G %h %H %I %j %m %M %n
%p %r %R %S %t %T %u %U %V %W %w %x %X %y %Y %Z %z %%", $t));
--
Edit bug report at http://bugs.php.net/?id=41501&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41501&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41501&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41501&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41501&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41501&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41501&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41501&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41501&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41501&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41501&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41501&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41501&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41501&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41501&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41501&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41501&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41501&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41501&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41501&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41501&r=mysqlcfg
#41495 [Opn->Bgs]: No Output at all on any php page
ID: 41495 Updated by: [EMAIL PROTECTED] Reported By: r dot homan at esoteric dot nl -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Vista Ultimate 32Bit PHP Version: 5.2.2 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2007-05-25 15:33:33] derek dot ethier at gmail dot com There is a problem with your Apache configuration or something has changed on the workstation that prevents PHP from being loaded correctly. Review the installation instructions (http://www.php.net/manual/en/install.windows.apache2.php) and check your event logs to see if any error is being thrown when Apache starts. [2007-05-25 06:48:13] r dot homan at esoteric dot nl Description: When i try to open a .php file via the Apache 2.2 running on Vista Ultimate, it gives no output at all, even if there's no PHP code in the file, but just html. When I change the extension to .html de server works fine. The strange thing is, that it has, in fact, worked fine. Reproduce code: --- Code i tested with is simple: the text: "het werkt!" (It works!) I've also tried Same output: none. Expected result: het werkt! ..or the phpinfo page. Actual result: -- Empty page, the code: -- Edit this bug report at http://bugs.php.net/?id=41495&edit=1
#41497 [Opn->Bgs]: php.ini not loaded
ID: 41497 Updated by: [EMAIL PROTECTED] Reported By: dbjh at gmx dot net -Status: Open +Status: Bogus Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: You've just used wrong configuration options. Please check "./configure --help" for more information. Note: all ini related options expect PATH to be passed, without the php.ini. (NOT full-path!) Previous Comments: [2007-05-25 13:25:45] dbjh at gmx dot net The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). [2007-05-25 11:46:51] dbjh at gmx dot net Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#41499 [Opn->Bgs]: ereg with null
ID: 41499
Updated by: [EMAIL PROTECTED]
Reported By: henrique at webcoder dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Debian Etch
PHP Version: 4.4.7
New Comment:
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
"Warning
These regular expression functions are not binary-safe. The PCRE
functions are. "
http://php.net/regex
Previous Comments:
[2007-05-25 14:23:55] henrique at webcoder dot com dot br
Description:
Hi!
Value %00 in the end of the regular expression is sent and the function
ereg() disrespects the remaining portion all.
Tested in the PHP 4.4.4-8+etch1
Thank you!
Henrique
Reproduce code:
---
function validateGender($gender)
{
return (ereg("^[MF]$", $gender)) ? $gender : false;
}
print "Gender: ". validateGender($_GET['gender']);
Expected result:
?gender=M%00test
Gender:
Actual result:
--
?gender=M%00test
Gender:M�test
--
Edit this bug report at http://bugs.php.net/?id=41499&edit=1
#41498 [Opn->Bgs]: switch..case output error
ID: 41498
Updated by: [EMAIL PROTECTED]
Reported By: eg dot soft at msa dot hinet dot net
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: windows xp
PHP Version: 5.2.2
New Comment:
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
Previous Comments:
[2007-05-25 16:12:20] crestfresh at gmail dot com
http://www.php.net/manual/en/language.operators.comparison.php
"If you compare an integer with a string, the string is converted to a
number. If you compare two numerical strings, they are compared as
integers. These rules also apply to the switch statement."
[2007-05-25 13:43:32] eg dot soft at msa dot hinet dot net
Description:
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
==> output: aa (Why?!)
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $b:
echo $b."\n";
break;
case $a:
echo $a."\n";
break;
default:
echo "default\n";
}
==> output: bb (Why?!)
Reproduce code:
---
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
Expected result:
default
Actual result:
--
aa
--
Edit this bug report at http://bugs.php.net/?id=41498&edit=1
#41498 [Com]: switch..case output error
ID: 41498
Comment by: crestfresh at gmail dot com
Reported By: eg dot soft at msa dot hinet dot net
Status: Open
Bug Type: Output Control
Operating System: windows xp
PHP Version: 5.2.2
New Comment:
http://www.php.net/manual/en/language.operators.comparison.php
"If you compare an integer with a string, the string is converted to a
number. If you compare two numerical strings, they are compared as
integers. These rules also apply to the switch statement."
Previous Comments:
[2007-05-25 13:43:32] eg dot soft at msa dot hinet dot net
Description:
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
==> output: aa (Why?!)
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $b:
echo $b."\n";
break;
case $a:
echo $a."\n";
break;
default:
echo "default\n";
}
==> output: bb (Why?!)
Reproduce code:
---
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
Expected result:
default
Actual result:
--
aa
--
Edit this bug report at http://bugs.php.net/?id=41498&edit=1
#41495 [Com]: No Output at all on any php page
ID: 41495 Comment by: derek dot ethier at gmail dot com Reported By: r dot homan at esoteric dot nl Status: Open Bug Type: Output Control Operating System: Vista Ultimate 32Bit PHP Version: 5.2.2 New Comment: There is a problem with your Apache configuration or something has changed on the workstation that prevents PHP from being loaded correctly. Review the installation instructions (http://www.php.net/manual/en/install.windows.apache2.php) and check your event logs to see if any error is being thrown when Apache starts. Previous Comments: [2007-05-25 06:48:13] r dot homan at esoteric dot nl Description: When i try to open a .php file via the Apache 2.2 running on Vista Ultimate, it gives no output at all, even if there's no PHP code in the file, but just html. When I change the extension to .html de server works fine. The strange thing is, that it has, in fact, worked fine. Reproduce code: --- Code i tested with is simple: the text: "het werkt!" (It works!) I've also tried Same output: none. Expected result: het werkt! ..or the phpinfo page. Actual result: -- Empty page, the code: -- Edit this bug report at http://bugs.php.net/?id=41495&edit=1
#41500 [NEW]: JSON encode limit should be variable
From: tobi at struckmeier dot name Operating system: irrelevant PHP version: 5.2.3RC1 PHP Bug Type: Feature/Change Request Bug description: JSON encode limit should be variable Description: Current nesting level is hardcoded to 128. Should be a parameter like string json_encode ( mixed $value [,int $limit] ) where $limit is an optional parameter that defaults to 128. -- Edit bug report at http://bugs.php.net/?id=41500&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41500&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41500&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41500&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41500&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41500&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41500&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41500&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41500&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41500&r=support Expected behavior:http://bugs.php.net/fix.php?id=41500&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41500&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41500&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41500&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41500&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41500&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41500&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41500&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41500&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41500&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41500&r=mysqlcfg
#41229 [Com]: PHP as fastcgi module crashes
ID: 41229
Comment by: host4cheap at yahoo dot com
Reported By: admin at torrent dot lt
Status: No Feedback
Bug Type: CGI related
Operating System: gentoo
PHP Version: 5.2.1
New Comment:
Any Updates on this. I face the same problem on CentOS with Lighttpd.
I get these ERROR after some time
2007-05-22 21:03:41: (log.c.75) server started
2007-05-22 21:33:53: (server.c.1149) NOTE: a request for
/forum/index.php?act=rssout&id=5 timed out after writing 13068 bytes. We
waited 360 seconds. If this a problem increase server.max-write-idle
2007-05-22 21:36:35: (server.c.1149) NOTE: a request for
/forum/index.php?showtopic=51680 timed out after writing 13032 bytes. We
waited 360 seconds. If this a problem increase server.max-write-idle
Until i restart Webserver, the problem is not fixed only to arise after
few hrs.
PHP Version 5.2.1
Previous Comments:
[2007-05-08 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2007-04-30 13:06:20] [EMAIL PROTECTED]
And no core files anywhere? find / -name 'core*' :)
[2007-04-29 23:21:32] admin at torrent dot lt
The ulimit thing was already done last Thursday, I have set these
variables as told. Nothing happened, the website is working fine, but
the traffic and the number of users are less than more ten times than in
a day.
"bin-path" => "/usr/bin/php-cgi", "max-procs" => 25, idle-timeout" =>
9,
"bin-environment" => ("PHP_FCGI_CHILDREN" => "1",
"PHP_FCGI_MAX_REQUESTS" => "10"
[2007-04-29 21:09:58] [EMAIL PROTECTED]
Start lighttpd without it forking. And only have 1 child for PHP
started. You don't need to "su lighttpd", just do the ulimit thing as
root.
[2007-04-29 20:02:39] admin at torrent dot lt
I have done the ulimit last week, but under uid0/gid0 I have set ulimit
-c unlimited under lighttpd user: su lighttpd ; ulimit -c unlimited,
what's more where I could expect the core file to be dumped? and how to
make it done?
I have just got the 500 error (after setting the ulimit) I reckon' that
before stating the 500 internal error the webserver is starting to act
extremely slow, the webpages hardly open's and so on. I have 1000
queries to mysql per sec.
Will be waiting for your answers.
I've got these errors.
http://p.defau.lt/?bNHoX3oyKfPWS80YDxIjAg
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/41229
--
Edit this bug report at http://bugs.php.net/?id=41229&edit=1
#41499 [NEW]: ereg with null
From: henrique at webcoder dot com dot br
Operating system: Debian Etch
PHP version: 4.4.7
PHP Bug Type: Feature/Change Request
Bug description: ereg with null
Description:
Hi!
Value %00 in the end of the regular expression is sent and the function
ereg() disrespects the remaining portion all.
Tested in the PHP 4.4.4-8+etch1
Thank you!
Henrique
Reproduce code:
---
function validateGender($gender)
{
return (ereg("^[MF]$", $gender)) ? $gender : false;
}
print "Gender: ". validateGender($_GET['gender']);
Expected result:
?gender=M%00test
Gender:
Actual result:
--
?gender=M%00test
Gender:M�test
--
Edit bug report at http://bugs.php.net/?id=41499&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41499&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41499&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41499&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41499&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41499&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41499&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41499&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41499&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41499&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41499&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41499&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41499&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41499&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41499&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41499&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41499&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41499&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41499&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41499&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41499&r=mysqlcfg
#41498 [NEW]: switch..case output error
From: eg dot soft at msa dot hinet dot net
Operating system: windows xp
PHP version: 5.2.2
PHP Bug Type: Output Control
Bug description: switch..case output error
Description:
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
==> output: aa (Why?!)
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $b:
echo $b."\n";
break;
case $a:
echo $a."\n";
break;
default:
echo "default\n";
}
==> output: bb (Why?!)
Reproduce code:
---
$a = 'aa';
$b = 'bb';
$value = 0;
switch ($value) {
case $a:
echo $a."\n";
break;
case $b:
echo $b."\n";
break;
default:
echo "default\n";
}
Expected result:
default
Actual result:
--
aa
--
Edit bug report at http://bugs.php.net/?id=41498&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41498&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41498&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41498&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41498&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41498&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41498&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41498&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41498&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41498&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41498&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41498&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41498&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41498&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41498&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41498&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41498&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41498&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41498&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41498&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41498&r=mysqlcfg
#41497 [Opn]: php.ini not loaded
ID: 41497 User updated by: dbjh at gmx dot net Reported By: dbjh at gmx dot net Status: Open Bug Type: PHP options/info functions Operating System: RHEL 4 PHP Version: 5.2.2 New Comment: The problem is also present on RHEL 5. The same workaround can be used. I meant phpinfo(), not php_info(). Previous Comments: [2007-05-25 11:46:51] dbjh at gmx dot net Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit this bug report at http://bugs.php.net/?id=41497&edit=1
#40740 [Asn]: PDO::execute() errors when parameters are used in LIMIT clause
ID: 40740
Updated by: [EMAIL PROTECTED]
Reported By: phpbugs at filofox dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux Debian Sarge 3.1
PHP Version: 5.2.1
Assigned To: wez
New Comment:
Well there is no way to hint to MySQL if something is a string or not
using emulate_prepare. What I think could make sense is for MySQL to
look at the type though.
So that:
$foo = '1'; // quoted as a string
$foo = 1; // interpreted as an integer and therefore not quoted
This should be fine for security as well, since integers should not
cause any SQL injection issues.
Of course this would break any code where people try to insert an
integer into a string column. But I think this would be very rare and
the benefit would out weight the disadvantages.
Previous Comments:
[2007-03-23 15:12:20] [EMAIL PROTECTED]
Emulation is wrong if it doesn't work. Numbers after LIMIT should not
be quoted.
[2007-03-07 09:54:18] [EMAIL PROTECTED]
Use PDO::ATTR_EMULATE_PREPARES = false to turn off emulation of
prepared statements.
PDO_MYSQL uses it by default because native prepared statements in
MySQL are quite limited - you can't use SHOW statements, for example.
The documentation should mention it, though.
Reclassified as docu problem.
[2007-03-06 17:13:44] phpbugs at filofox dot com
Description:
The following emerged after upgrading from 5.2.0 to 5.2.1 and has been
checked in both versions: the error only occurs in 5.2.1 .
When passing parameters into a LIMIT clause using PDO::execute(), it
appears that PDO is quoting the parameters, which causes MYSQL to throw
an error.
FYI: PDO_MYSQL is built against MySQL client library 5.0.18.
Reproduce code:
---
$dbh = new PDO('mysql:localhost;dbname=my_db', 'user', '' );
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
try{
$query = $dbh->prepare( 'SELECT * FROM some_table LIMIT :start,
:limit' );
if ( $query->execute ( array ( 'start' => 0, 'limit' => 10 ) ) )
{
while ( $row = $query->fetch ( PDO::FETCH_ASSOC ) )
{
print_r($row);
}
$query->closeCursor();
}
} catch( Exception $e ){
print_r( $e );
}
Expected result:
A number of rows are returned.
Actual result:
--
An exception is thrown:
PDOException Object
(
[message:protected] => SQLSTATE[42000]: Syntax error or access
violation: 1064 You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to
use near ''0', '10'' at line 1
[string:private] =>
[code:protected] => 42000
[file:protected] => [my_file].php
[line:protected] => 19
[trace:private] => Array
(
[0] => Array
(
[file] => [my_file].php
[line] => 19
[function] => execute
[class] => PDOStatement
[type] => ->
[args] => Array
(
[0] => Array
(
[start] => 0
[limit] => 10
)
)
)
)
[errorInfo] => Array
(
[0] => 42000
[1] => 1064
[2] => You have an error in your SQL syntax; check the
manual that corresponds to your MySQL server version for the right
syntax to use near ''0', '10'' at line 1
)
)
--
Edit this bug report at http://bugs.php.net/?id=40740&edit=1
#41497 [NEW]: php.ini not loaded
From: dbjh at gmx dot net Operating system: RHEL 4 PHP version: 5.2.2 PHP Bug Type: PHP options/info functions Bug description: php.ini not loaded Description: Problem: php.ini won't be loaded from /etc. When I set PHPIniDir in httpd.conf to /etc it still won't be loaded (judged from the output of php_info()). Workaround: When I set PHPIniDir to /etc/php/ and put php.ini in that directory it is loaded. Another workaround is putting php.ini in /etc/php.d/. In the latter case php_info() reports "(none)" at "Loaded Configuration File", but is mentioned at "additional .ini files parsed". Looking at other output of php_info() it is clear that it really is loaded. -- Edit bug report at http://bugs.php.net/?id=41497&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41497&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41497&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41497&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41497&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41497&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41497&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41497&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41497&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41497&r=support Expected behavior:http://bugs.php.net/fix.php?id=41497&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41497&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41497&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41497&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41497&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41497&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41497&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41497&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41497&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41497&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41497&r=mysqlcfg
#41496 [NEW]: Preg_Split returns 3 matches with offset -1
From: m_v_ at gmx dot net
Operating system: Windows Vista Home Premium
PHP version: 5CVS-2007-05-25 (snap)
PHP Bug Type: PCRE related
Bug description: Preg_Split returns 3 matches with offset -1
Description:
preg_split behaves unexpectet with certain pattern (see reproduce code):
It returns tripple offsets with the offsetvalue -1.
It gets even worse when you replace:
$reg = "~\{(literal)\}(.*?)\{(/literal)\}|\{(.*?)\}~s";
with
$reg = "~\{\*(literal)\}(.*?)\{(/literal)\}|\{(.*?)\}~s";
it simply returns several off those empty string, offset -1 triples.
P.S.: Hope it is actually a bug and not my ignorance of regex, however i
asked in a forum if anybody knew where the mistake is and i got no answer
and in addition the offset -1 mykes it look like a bug to me.
If it however should be a mistake in my regex it would be kind if you
would let me know how to put it.
Thx in advance
Reproduce code:
---
$reg = "~\{(literal)\}(.*?)\{(/literal)\}|\{(.*?)\}~s";
echo $reg.'';
$res = preg_split( $reg, "df{g}s{literal}asd{as}d{/literal}", -1,
PREG_SPLIT_DELIM_CAPTURE|PREG_SPLIT_OFFSET_CAPTURE );
echo ''.print_r($res, 1).'';
Expected result:
~\{(literal)\}(.*?)\{(/literal)\}|\{(.*?)\}~s
Array
(
[0] => Array
(
[0] => df
[1] => 0
)
[1] => Array
(
[0] => g
[1] => 3
)
[2] => Array
(
[0] => s
[1] => 5
)
[3] => Array
(
[0] => literal
[1] => 7
)
[4] => Array
(
[0] => asd{as}d
[1] => 15
)
[5] => Array
(
[0] => /literal
[1] => 24
)
[6] => Array
(
[0] =>
[1] => 33
)
)
Actual result:
--
~\{(literal)\}(.*?)\{(/literal)\}|\{(.*?)\}~s
Array
(
[0] => Array
(
[0] => df
[1] => 0
)
[1] => Array
(
[0] =>
[1] => -1
)
[2] => Array
(
[0] =>
[1] => -1
)
[3] => Array
(
[0] =>
[1] => -1
)
[4] => Array
(
[0] => g
[1] => 3
)
[5] => Array
(
[0] => s
[1] => 5
)
[6] => Array
(
[0] => literal
[1] => 7
)
[7] => Array
(
[0] => asd{as}d
[1] => 15
)
[8] => Array
(
[0] => /literal
[1] => 24
)
[9] => Array
(
[0] =>
[1] => 33
)
)
--
Edit bug report at http://bugs.php.net/?id=41496&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41496&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41496&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41496&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41496&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41496&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41496&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41496&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41496&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41496&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41496&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41496&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41496&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41496&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41496&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41496&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41496&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41496&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41496&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41496&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41496&r=mysqlcfg
