#41119 [Opn-Csd]: range() function behavior different on PHP6 and PHP5
ID: 41119
Updated by: [EMAIL PROTECTED]
Reported By: mahesh dot vemula at in dot ibm dot com
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: RHEL 4
PHP Version: 6CVS-2007-04-17 (snap)
New Comment:
Works fine on PHP 6.0.0-dev (cli) (built: Jan 14 2008 08:38:52)
Previous Comments:
[2007-04-17 13:48:03] mahesh dot vemula at in dot ibm dot com
Description:
Output of PHP5 and PHP6 differ for range() function. The difference
appears when an empty string() is given as low value and FLOAT as high
value. PHP5 gives the consistent output for an empty string and normal
string, which is an array of float elements.
Whereas PHP6 treats empty and normal strings differently when high
value is a FLOAT. The output of range() with an empty string() as low
value is array of Integer elements and with regular string as low
value is array of float elements.
Environment:
Operating System: RHEL 4
Linux Kernel : Linux 2.6.9
PHP Version: PHP 5.2 (Built on Apr 17, 2007 from snaps.php.net)
PHP Configure Setup: ./configure
Reproduce code:
---
?php
var_dump( range(, 2.2) );
var_dump( range(string, 2.2) );
?
Expected result:
array(3) {
[0]=
float(0)
[1]=
float(1)
[2]=
float(2)
}
array(3) {
[0]=
float(0)
[1]=
float(1)
[2]=
float(2)
}
Actual result:
--
PHP5 gives the output as expected but PHP6 gives the following output:
array(3) {
[0]=
int(0)
[1]=
int(1)
[2]=
int(2)
}
array(3) {
[0]=
float(0)
[1]=
float(1)
[2]=
float(2)
}
--
Edit this bug report at http://bugs.php.net/?id=41119edit=1
#43838 [NEW]: variant_set with IE leads to hang
From: csaba at alum dot mit dot edu
Operating system: Win XP Pro
PHP version: 5.2.5
PHP Bug Type: COM related
Bug description: variant_set with IE leads to hang
Description:
If an event sink is set on IE, and then a new window is created by that IE
(by clicking on a link with target=_blank, say), then NewWindow2 fires. By
replacing the first argument to NewWindow2 (via set_variant) it is possible
to identify the pending new ie and to assign a sink, $sink2, to it).
The problem is that the $sink2-ie is somehow corrupted to such an extent
that trying to access anything on it hangs ie badly.
There is a 2nd less severe but still significant problem: If the bug
causing 2 lines just above the print \n; in BeforeNavigate2 are commented
out, then the PHP code will terminate if either instance of IE is closed.
However, there is also an error genereated at the same time (the specific
error varies, but I suspect that it has to do with cleanup of the COM
objects).
Reproduce code:
---
?php
// set_variant bug testing
$aES = array(); // global array of IE event sinks
$newIEpage = body .
onload='document.links[0].click()' .
a target=_blank .
href='http://google.com'Goog/a/body;
$ie = new COM(InternetExplorer.Application);
sink_ie($ie);
$ie-visible = true;
$ie-Navigate2(about:blank);
while ($ie-ReadyState4) com_message_pump(200);
$ie-Navigate2(javascript:\$newIEpage\);
$ie-document-title = variant_set Launcher;
$keepLooping = true;
while ($keepLooping) com_message_pump(200);
print Exiting;
class mysink {
public $ie = null; // reqd for evt sink to function
function __construct($ie) { $this-ie = $ie; }
public function BeforeNavigate2 (
$ie, $url, $flags, $targetFrameName,
$postData, $headers, $cancel) {
print __FUNCTION__ . : . typename($ie) . , ;
print $ie-hwnd . , rs: . $ie-ReadyState;
print ; . $url . \n;
global $aES;
print Sink count: . sizeof($aES);
print , this-ie: ;
print typename($this-ie) . , ; // produces bug
print $this-ie-hwnd; // produces bug
print \n;
}
public function NewWindow2 ($newIe, $cancel) {
$ie = new COM(InternetExplorer.Application);
print NewWindow2: ;
variant_set($newIe, $ie);
$sink2 = sink_ie($ie);
print $sink2-ie-hwnd . \n;
}
public function DownloadComplete() {
print __FUNCTION__ . \n; }
public function DocumentComplete($dom, $url) {
print __FUNCTION__ . : $url\n; }
public function onQuit() { print Quitting\n;
$GLOBALS['keepLooping'] = false; }
}
function typename($objCOM) {
// similar to typename in vbscript
if (empty($objCOM)) return no COM object;
if (gettype($objCOM)!=object)
return not a COM object;
ob_start();
com_print_typeinfo($objCOM);
$typeInfo = ob_get_contents();
ob_end_clean();
$pattern = /^\\s*class (.*) \\{/;
if (!($matchCnt = preg_match($pattern,
$typeInfo, $aMatch)))
return Not found;
return COM: . $aMatch[1];
}
function sink_ie($ie) {
// sink $ie, and add to global array of sinks
global $aES;
com_event_sink ($ie, $aES[] = $sink =
new mysink($ie),
DWebBrowserEvents2);
return $sink;
}
?
Expected result:
This is PHP CLI code. When run from the cmd prompt, I expect two
instances of IE to come up (they do), and for the cmd prompt to display the
navigation progress.
Now I could see that $sink2-ie becomes obsolete somehow (even though its
hwnd is the same as the hwnd that comes into BeforeNavigate2), but what
seems really wrong is to get a hang upon trying to do anything with that
variable in BeforeNavigate2 (either $this-ie or $aES[sizeof($aES)-1]-ie)
Actual result:
--
If the included script is run as is, then typename($this-ie) causes a
hang. If it is commented out, $this-ie-hwnd causes a hang. If both of
these statements (the two lines before the last print statement in
BeforeNavigate2) are commented out, then both IE pages will load OK (ie.
the main bug goes away), and there will only be issues when the php code
shuts down on account of one of the two IE's being closed.
A note about the code: While it may appear somewhat convoluted, the point
of the original code was to track navigation progress within ie, and this
works fine. However, when (simulated) clicking on a link causes the
browser to open a new window, then navigation tracking must continue with a
new ie, and the way to get ahold of that ie is with the NewWindow2 or
NewWindow3 event, and I used the former.
Two things need to happen in NewWindow2. The first is that the first
argument to the event handler needs to be set to an uninitiated, fresh IE.
The second is that this new IE needs to be sinked. Because we're in an
event handler, globals are not so good, but since event sinks require a
reference to their COM object, the sink gets an IE variable. The variable
is not superfluous: if you make
#43839 [NEW]: Cast problem with the equal operator (==)
From: technique at ircf dot fr
Operating system: Linux Ubuntu
PHP version: 5.2CVS-2008-01-14 (snap)
PHP Bug Type: Scripting Engine problem
Bug description: Cast problem with the equal operator (==)
Description:
I have noticed that the equal operator will systematically try to cast
expressions as integers, even when it is useless.
This may cause problems like this (see the code below).
Wouldn't be better to cast only one operand ONLY if the two operands are
not of the same type ? For example :
1 == 1 , would cast the right operand (1) as a string and then compare
it with the first
123 == 456, would not cast any operand because they already have the
same type
I know that this issue can be solved using the identity operator (===) but
I find weird that 001 == 0001 returns true, or am I missing something ?
Reproduce code:
---
?php
if (0001 == 01){
echo Impossible !!!;
}
?
Expected result:
Nothing
Actual result:
--
Impossible !!!
--
Edit bug report at http://bugs.php.net/?id=43839edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43839r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43839r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43839r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43839r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43839r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43839r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43839r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43839r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43839r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43839r=support
Expected behavior:http://bugs.php.net/fix.php?id=43839r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43839r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43839r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43839r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43839r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43839r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43839r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43839r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43839r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43839r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43839r=mysqlcfg
#43835 [Opn-Bgs]: misstyped fields num in actual results
ID: 43835
Updated by: [EMAIL PROTECTED]
Reported By: alexander dot varchenko at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: FreeBSD,Linux,Windows
PHP Version: 5.2.5
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.
An invalid CSV format is not going to be supported. The enclosure
character needs to be escaped to ensure proper data parsing.
Previous Comments:
[2008-01-14 00:20:23] alexander dot varchenko at gmail dot com
! In Actual Result - 3 fields in line x
[2008-01-14 00:17:07] alexander dot varchenko at gmail dot com
Description:
Not every programs escapes enclosure characters,
so it's should be good to check enclosures by delimiters chars
start =delimiter+enclosure
fin = enclosure+delimiter
TEST data: test.csv [TSV]
1[tab]NOAA Official Emergency[tab]01/09/2008
2[tab]Tories reject green panel's advice[tab]01/09/2008
Reproduce code:
---
?
$handle = fopen('test.csv','rb');
$row = 1;
while (($data = fgetcsv($handle, 1000, \t,'')) !== FALSE) {
$num = count($data);
echo $num fields in line $row\n;
$row++;
for ($c=0; $c $num; $c++) {
echo [$c]:.$data[$c].\n;
}
}
fclose($handle);
?
Expected result:
3 fields in line 1
[0]:1
[1]:NOAA Official Emergency
[2]:01/09/2008
3 fields in line 2
[0]:2
[1]:Tories reject green panel's advice
[2]:01/09/2008
Actual result:
--
4 fields in line 1
[0]:1
[1]:NOAA Official Emergency
[2]:01/09/2008
4 fields in line 2
[0]:2
[1]:Tories reject green panel's advice
[2]:01/09/2008
--
Edit this bug report at http://bugs.php.net/?id=43835edit=1
#43839 [Opn-Bgs]: Cast problem with the equal operator (==)
ID: 43839
Updated by: [EMAIL PROTECTED]
Reported By: technique at ircf dot fr
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux Ubuntu
PHP Version: 5.2CVS-2008-01-14 (snap)
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
Numeric strings are understood as numeric values. This is not exactly
an int cast.
i.e. 01a == 001a is not true, as the operands are not numeric.
however (int)01a == (int)001a == 1
Previous Comments:
[2008-01-14 13:33:25] technique at ircf dot fr
Description:
I have noticed that the equal operator will systematically try to cast
expressions as integers, even when it is useless.
This may cause problems like this (see the code below).
Wouldn't be better to cast only one operand ONLY if the two operands
are not of the same type ? For example :
1 == 1 , would cast the right operand (1) as a string and then
compare it with the first
123 == 456, would not cast any operand because they already have
the same type
I know that this issue can be solved using the identity operator (===)
but I find weird that 001 == 0001 returns true, or am I missing
something ?
Reproduce code:
---
?php
if (0001 == 01){
echo Impossible !!!;
}
?
Expected result:
Nothing
Actual result:
--
Impossible !!!
--
Edit this bug report at http://bugs.php.net/?id=43839edit=1
#34667 [Com]: Notice: Unknown: Unable to find the wrapper compress.bzip2.....
ID: 34667 Comment by: lord dot arrogant at gmail dot com Reported By: webmaster at 24-99-92-156 dot no-ip dot com Status: No Feedback Bug Type: Bzip2 Related Operating System: Windows Server 2003 Ent. SP1 PHP Version: 5.0.5 New Comment: I am running 5.2.5 on WinXP Pro with Apache 2.2.6 and the error is always there when I first open my browser and load a page. If I reload the page immediately the error disappears. I have loaded the bz2. Previous Comments: [2008-01-03 18:04:38] jpenn at rcn dot com I am running PHP 5.2.5 Windows 2000 server and IIS 5. I get the same error when error_reporting = E_ALL is set in the php.ini file. I have it set to E_STRICT and I am no longer recieving this error. JP [2008-01-03 17:04:39] computerlov at yahoo dot com Here's how to reproduce the bug: you need to have your php.ini file configured to display errors and show errors E_ALL | E_STRICT I had E_ALL and it didn't show up. Once adding E_STRICT, it started popping as reported before. Maybe the new snapshot didn't have E_STRICT in the ini file. Php version i'm using: 5.2.5 (Downloaded it in December 2007) I'm using windows binaries. Cheers. [2007-11-12 13:41:39] abouzekry at gmail dot com The Problem also appears to exist in PHP 5.2.0, on WinXP Professional,...but the probability of it's appear is random!!! [2007-09-16 14:31:33] gfj at gfhdf dot hgi http://www.meta-fx.com [2006-11-10 19:28:07] saulovallory at yahoo dot com I was having the same problem. The last snapshot (link above) solved 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/34667 -- Edit this bug report at http://bugs.php.net/?id=34667edit=1
#43207 [Com]: .htaccess settings missing (sometimes)
ID: 43207 Comment by: dan at eskhosting dot com Reported By: phpmyforum at gmail dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 5.2.5RC2 New Comment: register_globals are switching On/Off randomise! Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no difference. Only global setting in php.ini are effective. Other variables works good. System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6) PHP: 5.2.5 './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--prefix=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc' '--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2' Apache: 1.3.37 Previous Comments: [2007-11-19 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. [2007-11-11 18:49:12] [EMAIL PROTECTED] Try change the php_flag to php_value and use 0 or 1 as value. [2007-11-06 18:25:23] phpmyforum at gmail dot com Description: Since I upgraded from php4 to PHP 5.2.5RC2 .htaccess php_* options getting ignored. This happens for most, but not all requests. The default (php.ini) option for register_globals is off. My .htaccess file looks like this: php_flag register_globals on Now I downgraded to PHP 5.2.4 and it's working again. Hint: this bug looks very similar to #28522. PS: this may happen for other options './configure' '--prefix=/bbo/php' '--with-apxs2=/bbo/apachessl/bin/apxs' '--with-config-file-path=/bbo/etc/httpd' '--with-openssl=/bbo/usr' '--with-zlib' '--with-zlib-dir=/bbo/usr' '--with-bz2=/bbo/usr' '--enable-ftp' '--enable-exif' '--with-gd=/bbo/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=/bbo/usr' '--with-png-dir=/bbo/usr' '--with-freetype-dir=/bbo/usr' '--with-mysql=/bbo/usr' '--with-mysqli=/bbo/usr/bin/mysql_config' '--with-pdo-mysql=/bbo/usr' '--with-iconv' '--with-iconv-dir=/bbo/usr' '--with-curl=/bbo/usr' '--with-curlwrappers' '--enable-soap' '--enable-sockets' '--enable-mbstring=all' '--enable-mbregex' '--with-xsl=/bbo/usr' '--with-libxml-dir=/bbo/usr' '--with-pspell=/bbo/usr' '--with-ldap=/bbo/usr' '--with-tidy=/bbo/usr' '--with-gettext=/bbo/usr' '--with-mcrypt=/bbo/usr' '--with-pcre-regex=/bbo/usr' '--enable-sigchild' '--enable-sysvshm' '--enable-sysvsem' '--enable-zip' '--disable-short-tags' '--with-pear=/bbo/php_includes' '--with-imap=/download/webserver/files/imap/' '--with-imap-ssl' '--without-kerberos' -- Edit this bug report at http://bugs.php.net/?id=43207edit=1
#43207 [Com]: .htaccess settings missing (sometimes)
ID: 43207 Comment by: dan at eskhosting dot com Reported By: phpmyforum at gmail dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 5.2.5RC2 New Comment: php_value/php_flag - no different too. Previous Comments: [2008-01-14 16:05:14] dan at eskhosting dot com register_globals are switching On/Off randomise! Values: 1/On/true, 0/Off/false; place: .htacess, httpd.conf - no difference. Only global setting in php.ini are effective. Other variables works good. System: Red Hat Enterprise Linux ES release 4 (Nahant Update 6) PHP: 5.2.5 './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--prefix=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-curl' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext' '--with-iconv' '--enable-mbstring' '--enable-mbregex' '--with-mcrypt' '--enable-magic-quotes' '--with-mysqli' '--with-mysql=/usr' '--with-openssl' '--enable-discard-path' '--with-pear' '--with-pgsql=/usr' '--enable-safe-mode' '--enable-sockets' '--with-ttf' '--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--with-xmlrpc' '--with-xsl=/usr' '--enable-zip' '--with-zlib' '--with-bz2' Apache: 1.3.37 [2007-11-19 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. [2007-11-11 18:49:12] [EMAIL PROTECTED] Try change the php_flag to php_value and use 0 or 1 as value. [2007-11-06 18:25:23] phpmyforum at gmail dot com Description: Since I upgraded from php4 to PHP 5.2.5RC2 .htaccess php_* options getting ignored. This happens for most, but not all requests. The default (php.ini) option for register_globals is off. My .htaccess file looks like this: php_flag register_globals on Now I downgraded to PHP 5.2.4 and it's working again. Hint: this bug looks very similar to #28522. PS: this may happen for other options './configure' '--prefix=/bbo/php' '--with-apxs2=/bbo/apachessl/bin/apxs' '--with-config-file-path=/bbo/etc/httpd' '--with-openssl=/bbo/usr' '--with-zlib' '--with-zlib-dir=/bbo/usr' '--with-bz2=/bbo/usr' '--enable-ftp' '--enable-exif' '--with-gd=/bbo/usr' '--enable-gd-native-ttf' '--with-jpeg-dir=/bbo/usr' '--with-png-dir=/bbo/usr' '--with-freetype-dir=/bbo/usr' '--with-mysql=/bbo/usr' '--with-mysqli=/bbo/usr/bin/mysql_config' '--with-pdo-mysql=/bbo/usr' '--with-iconv' '--with-iconv-dir=/bbo/usr' '--with-curl=/bbo/usr' '--with-curlwrappers' '--enable-soap' '--enable-sockets' '--enable-mbstring=all' '--enable-mbregex' '--with-xsl=/bbo/usr' '--with-libxml-dir=/bbo/usr' '--with-pspell=/bbo/usr' '--with-ldap=/bbo/usr' '--with-tidy=/bbo/usr' '--with-gettext=/bbo/usr' '--with-mcrypt=/bbo/usr' '--with-pcre-regex=/bbo/usr' '--enable-sigchild' '--enable-sysvshm' '--enable-sysvsem' '--enable-zip' '--disable-short-tags' '--with-pear=/bbo/php_includes' '--with-imap=/download/webserver/files/imap/' '--with-imap-ssl' '--without-kerberos' -- Edit this bug report at http://bugs.php.net/?id=43207edit=1
#43841 [NEW]: mb_strrpos offset is byte count for negative values
From: josmessa at uk dot ibm dot com
Operating system: Windows XP
PHP version: 5.2CVS-2008-01-14 (snap)
PHP Bug Type: mbstring related
Bug description: mb_strrpos offset is byte count for negative values
Description:
The offset argument appears to do a byte count for negative values of
offset.
In the example below, $string_ascii is 21 characters long and $string_mb
is 21 characters (53 bytes) long. In both cases the needle appears twice,
first at position 9 and secondly at position 20.
When the offset is -24, beyond the character length of the string, it
finds $needle at position 9, when $needle would be expected to be found
when offest is -12 (i.e. behave the same as the ASCII example).
It's also worth noting that strrpos returns a notice when the offset is
outside the boundary of the string whereas mb_strrpos does not.
This may be linked to this bug: http://bugs.php.net/43840.
Reproduce code:
---
?php
$offsets = array(-25, -24, -13, -12);
$string_mb =
base64_decode('5pel5pys6Kqe44OG44Kt44K544OI44Gn44GZ44CCMDEyMzTvvJXvvJbvvJfvvJjvvJnjgII=');
$needle = base64_decode('44CC');
foreach ($offsets as $i) {
echo \n-- Offset is $i --\n;
echo Multibyte String:\t;
var_dump( mb_strrpos($string_mb, $needle, $i, 'UTF-8') );
echo ASCII String:\n;
echo mb_strrpos:\t\t;
var_dump(mb_strrpos('This is na English ta', 'a', $i));
echo strrpos:\t\t;
var_dump(strrpos('This is na English ta', 'a', $i));
}
?
Expected result:
-- Offset is -25 --
Multibyte String:
Notice: mb_strrpos(): Offset is greater than the length of haystack string
in ...\mb_strrpos.php on line 9
bool(false)
ASCII String:
mb_strrpos:
Notice: mb_strrpos(): Offset is greater than the length of haystack string
in ...\mb_strrpos.php on line 14
bool(false)
strrpos:
Notice: strrpos(): Offset is greater than the length of haystack string in
...\mb_strrpos.php on line 14
bool(false)
-- Offset is -24 --
Multibyte String:
Notice: mb_strrpos(): Offset is greater than the length of haystack string
in ...\mb_strrpos.php on line 9
bool(false)
ASCII String:
mb_strrpos:
Notice: mb_strrpos(): Offset is greater than the length of haystack string
in ...\mb_strrpos.php on line 14
bool(false)
strrpos:
Notice: strrpos(): Offset is greater than the length of haystack string in
...\mb_strrpos.php on line 14
bool(false)
-- Offset is -13 --
Multibyte String: bool(false)
ASCII String:
mb_strrpos: bool(false)
strrpos:bool(false)
-- Offset is -12 --
Multibyte String: int(9)
ASCII String:
mb_strrpos: int(9)
strrpos:int(9)
Actual result:
--
-- Offset is -25 --
Multibyte String: bool(false)
ASCII String:
mb_strrpos: bool(false)
strrpos:
Notice: strrpos(): Offset is greater than the length of haystack string in
...\mb_strrpos.php on line 14
bool(false)
-- Offset is -24 --
Multibyte String: int(9)
ASCII String:
mb_strrpos: bool(false)
strrpos:
Notice: strrpos(): Offset is greater than the length of haystack string in
...\mb_strrpos.php on line 14
bool(false)
-- Offset is -13 --
Multibyte String: int(9)
ASCII String:
mb_strrpos: bool(false)
strrpos:bool(false)
-- Offset is -12 --
Multibyte String: int(9)
ASCII String:
mb_strrpos: int(9)
strrpos:int(9)
--
Edit bug report at http://bugs.php.net/?id=43841edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43841r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43841r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43841r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43841r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43841r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43841r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43841r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43841r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43841r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43841r=support
Expected behavior:http://bugs.php.net/fix.php?id=43841r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43841r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43841r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43841r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43841r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43841r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43841r=isapi
Install GNU Sed:
#43840 [NEW]: mb_strpos bounds check is byte count rather than a character count
From: josmessa at uk dot ibm dot com
Operating system: Windows XP
PHP version: 5.2CVS-2008-01-14 (snap)
PHP Bug Type: mbstring related
Bug description: mb_strpos bounds check is byte count rather than a character
count
Description:
The bounds check for the offest argument in mb_strpos appears to be a byte
count rather than a character count.
In the example below, $string_ascii is 21 characters long and $string_mb
is 21 characters (53 bytes) long. In both cases the needle appears twice,
first at position 9 and secondly at position 20.
With the multibyte string example, when the offset is past the character
count of the string it would be expected to return a warning but instead a
warning is returned when offest is past the byte count.
Reproduce code:
---
?php
$offsets = array(20, 21, 22, 53, 54);
$string_mb =
base64_decode('5pel5pys6Kqe44OG44Kt44K544OI44Gn44GZ44CCMDEyMzTvvJXvvJbvvJfvvJjvvJnjgII=');
$needle = base64_decode('44CC');
foreach($offsets as $i) {
echo \n-- Offset is $i --\n;
echo --Multibyte String:--\n;
var_dump( mb_strpos($string_mb, $needle, $i, 'UTF-8') );
echo--ASCII String:--\n;
var_dump(mb_strpos('This is na English ta', 'a', $i));
}
?
Expected result:
-- Offset is 20 --
--Multibyte String:--
int(20)
--ASCII String:--
int(20)
-- Offset is 21 --
--Multibyte String:--
bool(false)
--ASCII String:--
bool(false)
-- Offset is 22 --
--Multibyte String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 9
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
-- Offset is 53 --
--Multibyte String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 9
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
-- Offset is 54 --
--Multibyte String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 9
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
Actual result:
--
-- Offset is 20 --
--Multibyte String:--
int(20)
--ASCII String:--
int(20)
-- Offset is 21 --
--Multibyte String:--
bool(false)
--ASCII String:--
bool(false)
-- Offset is 22 --
--Multibyte String:--
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
-- Offset is 53 --
--Multibyte String:--
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
-- Offset is 54 --
--Multibyte String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 9
bool(false)
--ASCII String:--
Warning: mb_strpos(): Offset not contained in string. in ...\mb_strpos.php
on line 11
bool(false)
--
Edit bug report at http://bugs.php.net/?id=43840edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43840r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43840r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43840r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43840r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43840r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43840r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43840r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43840r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43840r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43840r=support
Expected behavior:http://bugs.php.net/fix.php?id=43840r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43840r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43840r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43840r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43840r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43840r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43840r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43840r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43840r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43840r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43840r=mysqlcfg
#43842 [Opn]: gerister_globals randomise switching value On/Off
ID: 43842 User updated by: dan at eskhosting dot com Reported By: dan at eskhosting dot com Status: Open Bug Type: *Configuration Issues Operating System: Linux Red Hat ES 4 PHP Version: 5.2.5 New Comment: Apache 1.3.37 PHP as module. 5.2.3 worked without this problem.. Previous Comments: [2008-01-14 16:54:29] dan at eskhosting dot com Description: Set up value for gerister_globals take a random effect. Reproduce code: --- php.ini: register_globals = Off .htaccess: php_flag register_globals On Expected result: register_globals On Actual result: -- ? phpinfo(); ? reports: register_globals On/Off - randomise! -- Edit this bug report at http://bugs.php.net/?id=43842edit=1
#36923 [Com]: PDO::query fails when query contains special charactes
ID: 36923
Comment by: stoto98 at yahoo dot fr
Reported By: farin at refresh dot cz
Status: No Feedback
Bug Type: PDO related
Operating System: Gentoo
PHP Version: 5.1.2
New Comment:
Same error for me with PHP 5.2.0-8+etch9 (debian) with client library
version 5.0.32 (MySQL)
Previous Comments:
[2007-10-04 11:24:17] gizmo dot rafal at poczta dot fm
I have same issue on my PHP Version 5.2.3-0.dotdeb.1 with PDO Driver
for MySQL, client library version 5.0.41.
[2007-08-09 22:36:01] apike at sfu dot ca
This is still happening for me with PHP 5.2.0.
[2006-04-07 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.
[2006-03-30 13:29:53] [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-03-30 13:27:39] farin at refresh dot cz
Description:
When $query parameter for PDO::query contains
' :A and ? (as part of data) query fails with error
Invalid parameter number: mixed named and positional parameters. This
behavior is appear with PDO mysql driver. In PHP 5.1.1 is not this bug
present.
Reproduce code:
---
$pdo-query(insert into foo (bar) values ('\\ ? :A'));
Expected result:
SQL syntax is Ok so query should be proccessed without error.
Actual result:
--
Warning: PDO::query() [function.query]: SQLSTATE[HY093]: Invalid
parameter number: mixed named and positional parameters in ...
And query fails.
--
Edit this bug report at http://bugs.php.net/?id=36923edit=1
#43844 [NEW]: muliple odbc_execute() on prepared select statement with bind parms (IBM ODBC)
From: kennya at carlislefsp dot com
Operating system: Debian Linux 4.0
PHP version: 5.2.5
PHP Bug Type: ODBC related
Bug description: muliple odbc_execute() on prepared select statement with bind
parms (IBM ODBC)
Description:
OS: Debian Linux 4.0
PHP: 5.2.0-8+etch9 and 5.2.25
unixODBC: 2.2.11-13
ODBC Driver: IBM iSeries Access for Linux V5R4, Version 1.4
Second execution of a prepared select statement with bind parameters
fails.
Through trial and error, I found that it'll actually work if I:
#1) don't define any variables between odbc_execute()
#2) cycle through all of the results
OR
comment out the SQLFreeStmt(.. SQL_RESET_PARAMS) in ext/odbc/php_odbc.c
line #1102, ie:
--cut--
if (result-numparams 0) {
/* SQLFreeStmt(result-stmt, SQL_RESET_PARAMS); */
for(i = 0; i result-numparams; i++) {
if (params[i].fp != -1)
close(params[i].fp);
}
efree(params);
}
--cut--
I'm not a C guy. I figure the above is present for a reason, I've just
noticed that removing it fixes this problem for this version of of the IBM
ODBC/DB2 driver.
Reproduce code:
---
$conn = odbc_connect('host','user','pass');
$stmt='select cn from ldapusr where cn like ?';
$res =odbc_prepare($conn, $stmt);
if (! odbc_execute($res, array('%ken%'))) {
trigger_error(odbc_error($conn) . ': ' . odbc_errormsg($conn),
E_USER_ERROR);
}
if (odbc_fetch_row($res)) {
print odbc_result($res, 1) . \n;
}
//$anything='asdf'; // add this and it stops working
while (odbc_fetch_row($res)) {} // remove this and it stops working
print 'Second:\n';
if (! odbc_execute($res, array('%steve%'))) {
trigger_error(odbc_error($conn) . ': ' . odbc_errormsg($conn),
E_USER_ERROR);
}
if (odbc_fetch_row($res)) {
print odbc_result($res, 1) . \n;
}
Expected result:
records
Actual result:
--
07001: [unixODBC][IBM][iSeries Access ODBC Driver]Wrong number of
parameters.
--
Edit bug report at http://bugs.php.net/?id=43844edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43844r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43844r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43844r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43844r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43844r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43844r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43844r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43844r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43844r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43844r=support
Expected behavior:http://bugs.php.net/fix.php?id=43844r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43844r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43844r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43844r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43844r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43844r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43844r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43844r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43844r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43844r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43844r=mysqlcfg
#43845 [NEW]: Function can no longer be called both statically and as instance method
From: ms419 at freezone dot co dot uk
Operating system:
PHP version: 5.2.5
PHP Bug Type: Feature/Change Request
Bug description: Function can no longer be called both statically and as
instance method
Description:
I understand that, unlike some other languages, PHP does not support
overloading: I can't implement two functions with the same name but
different signatures. However I can simulate overloading using
func_get_args() and testing with which arguments the function was called.
Now what I want is a function which can be called either as an instance
method with no arguments, or statically with one argument: an instance of
the class. I test whether the function was called statically or not using
isset($this)
However in PHP5, this produces an error:
Non-static method BaseTaxonomy::getTerms() should not be called statically
in...
Like it is possible to simulate overloading in PHP without generating
errors, I wish it were possible to define a function which can be called
either statically or as an instance method, without generating errors.
Much thanks, Jack
Reproduce code:
---
Toy example:
class BaseTaxonomy
{
protected $terms = null;
public function getTerms()
{
if (!isset($this))
{
$args = func_get_args();
return $args[0]-terms;
}
return $this-terms;
}
}
Actual result:
--
Non-static method BaseTaxonomy::getTerms() should not be called statically
in...
--
Edit bug report at http://bugs.php.net/?id=43845edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43845r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43845r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43845r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43845r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43845r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43845r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43845r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43845r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43845r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43845r=support
Expected behavior:http://bugs.php.net/fix.php?id=43845r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43845r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43845r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43845r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43845r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43845r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43845r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43845r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43845r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43845r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43845r=mysqlcfg
#41888 [Asn]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 User updated by: hans at velum dot net Reported By: hans at velum dot net Status: Assigned Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.4 Assigned To: iliaa New Comment: Any idea when this issue might get fixed? This is a big deal to us, since this bug prevents us from swapping out filesystem-based storage with a db-storage engine. Previous Comments: [2007-10-01 20:04:40] hans at velum dot net Updating version to reflect that problem is still present in 5.2.4 [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! [2007-09-06 13:36:53] hans at velum dot net Any update on this ticket? I just confirmed that this is still segfaulting in latest 5.2.4 PHP release. [2007-07-03 12:58:52] hans at velum dot net Description: I am trying to use PDO LOB columns with PostgreSQL within a user-defined stream wrapper class. PDO is correctly handling the LOB with PostgreSQL as stream resources; however, when I attempt to update a LOB column using another stream (e.g. php://temp, php://memory) in my stream_flush() command, I get a segmentation fault. Reproduce code: --- I was able to create a basic reproduce case; however, it is more than 20 lines of code. Here is a link to a snippet that creates the stream wrapper and attempts to perform an update: http://pastebin.com/941246 This consistently segfaults in my environment. Expected result: No segfault. Actual result: -- Segfault. I have PHP compiled w/ debug flags; however, the backtrace in this case is very unhelpful. Program terminated with signal 11, Segmentation fault. #0 0x0830aabd in _zval_dtor_func () (gdb) bt #0 0x0830aabd in _zval_dtor_func () #1 0x082fdf90 in ?? () #2 0x0870bf34 in ?? () #3 0x085bdec4 in ?? () #4 0x0023 in ?? () #5 0x085c0268 in ?? () #6 0x0001 in ?? () #7 0x0001 in ?? () #8 0xbf8f0108 in ?? () #9 0x082fe146 in _zval_ptr_dtor () Backtrace stopped: frame did not save the PC (gdb) -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#43846 [NEW]: Switch statement broken when using 'null' value
From: php_bug at jldupont dot com
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: Scripting Engine problem
Bug description: Switch statement broken when using 'null' value
Description:
The 'switch' statement does not correctly handle the case where the switch
value === null.
Reproduce code:
---
The following code should show null, true, false:
function testSwitch( $v )
{
return $v;
}
function showResult( $r )
{
$v = testSwitch( $r );
switch ($v)
{
case false:
echo false;
break;
case null:
echo null;
break;
case true:
echo true;
break;
}
echo \nbr/;
}
showResult( null );
showResult( true );
showResult( false );
Expected result:
null
true
false
Actual result:
--
false
true
false
--
Edit bug report at http://bugs.php.net/?id=43846edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43846r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43846r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43846r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43846r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43846r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43846r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43846r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43846r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43846r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43846r=support
Expected behavior:http://bugs.php.net/fix.php?id=43846r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43846r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43846r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43846r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43846r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43846r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43846r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43846r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43846r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43846r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43846r=mysqlcfg
#43846 [Opn-Bgs]: Switch statement broken when using 'null' value
ID: 43846
Updated by: [EMAIL PROTECTED]
Reported By: php_bug at jldupont dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.5
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:
[2008-01-14 21:21:36] php_bug at jldupont dot com
Description:
The 'switch' statement does not correctly handle the case where the
switch value === null.
Reproduce code:
---
The following code should show null, true, false:
function testSwitch( $v )
{
return $v;
}
function showResult( $r )
{
$v = testSwitch( $r );
switch ($v)
{
case false:
echo false;
break;
case null:
echo null;
break;
case true:
echo true;
break;
}
echo \nbr/;
}
showResult( null );
showResult( true );
showResult( false );
Expected result:
null
true
false
Actual result:
--
false
true
false
--
Edit this bug report at http://bugs.php.net/?id=43846edit=1
#41608 [Opn-Fbk]: Apache crash because of script
ID: 41608
Updated by: [EMAIL PROTECTED]
Reported By: aigors at inbox dot lv
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.2.5
Assigned To: tony2001
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Previous Comments:
[2007-12-18 09:47:50] aigors at inbox dot lv
Bug still exists in PHP 5.2.5.
[2007-06-06 08:35:53] [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.
[2007-06-06 07:44:20] aigors at inbox dot lv
Description:
Apache crash because of script containing set_error_handler function.
Reproduce code:
---
/***Main php file***/
?php
function MyErrorHandler($errno, $errstr, $errfile, $errline){
include_once('empty.php');
}
set_error_handler(MyErrorHandler);
include_once('blah.php');
echo('I am done');
?
/***blah.php file***/
?php
class Blah {
function foo($value, $classname) {
switch(strtolower($value['key'])) {
default: $x = new $classname;
}
}
}
?
/***empty.php file - no content***/
Expected result:
Should output I am done
Actual result:
--
Apache crash
--
Edit this bug report at http://bugs.php.net/?id=41608edit=1
#42443 [Com]: PDO SQLite3 lacks integer type support
ID: 42443 Comment by: lapo at lapo dot it Reported By: [EMAIL PROTECTED] Status: Open Bug Type: SQLite related Operating System: * PHP Version: 6CVS-2007-08-27 (CVS) New Comment: Even worse than the integer case (which leads to inefficience) is the case of BLOBs, which leads to corruption of data: text values can't contain \0, while blob data can. E.g. from command line sqlite3: sqlite SELECT LENGTH(X'1200'); 4 sqlite SELECT LENGTH(CAST(X'1200' AS text)); 1 Because case PDO_PARAM_LOB falls through to case PDO_PARAM_STR, which uses sqlite3_bind_text... using PDO is impossible to store BLOB data in Sqlite3. Previous Comments: [2007-08-27 10:42:16] [EMAIL PROTECTED] Description: PDO SQLite3 calls sqlite3_bind_text() for all non-blob and non-null parameter types regardless of whether integer data is provided. Integer data can be bound with sqlite3_bind_int(), which saves memory space and improves efficiency, as well as storing the intended type in a database which uses SQLite3's value typing. Patch is at: http://news.php.net/php.internals/31935 Reproduce code: --- Difficult to show reproduction. Expected result: Difficult to show reproduction. Actual result: -- Difficult to show reproduction. -- Edit this bug report at http://bugs.php.net/?id=42443edit=1
#42850 [Opn-Csd]: array_walk_recursive() leaves references
ID: 42850
Updated by: [EMAIL PROTECTED]
Reported By: ltaupiac at lfdj dot com
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: windows/solaris
PHP Version: 5.3.0-dev
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-11-26 08:00:18] ltaupiac at lfdj dot com
I have tested on window with apache 2.2.6 the snap.zip you given.
The bug is still there.
A for reference is still leaved after call array_walk_recursive on
val2 and original array can't be duplicate anymore after.
Reproduce code:
--
echo PHP_VERSION;
$data = array ('key1' = 'val1', array('key2' = 'val2'));
echo 'pre';
function foo2($item, $key) {}; // dumb callback function
var_dump($data);
array_walk_recursive($data, 'foo2');
$data2 = $data; // Duplicate array
$data2[0] = 'altered'; // Alter copy
var_dump($data);
var_dump($data2);
Expected result:
5.3.0-dev
array(2) {
[key1]=
string(4) val1
[0]=
array(1) {
[key2]=
string(4) val2
}
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) val2
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
Actual result:
--
5.3.0-dev
array(2) {
[key1]=
string(4) val1
[0]=
array(1) {
[key2]=
string(4) val2
}
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
array(2) {
[key1]=
string(4) val1
[0]=
string(7) altered
}
[2007-11-25 17:35:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
[2007-10-04 08:10:34] ltaupiac at lfdj dot com
Description:
I have to reopen this bug http://bugs.php.net/bug.php?id=42655 because
it was incorrectly closed and tony2001 doesn't seem to receive email.
Here Copy/paste email i send him.
This is not the same bug.
In #34982, an array is modified outside the function func() that call
array_walk_recursive. This bug doesn't exist anymore in 5.2.4
The bug i report is when calling array_walk_recursive on an array
(callback function doesn't even have reference for array input and
does nothing).
Original array shouldn't be modified, but if you var_dump it, you can
see reference on subarray
[0]= array(1)
instead of
[0]= array(1)
The array shouldn't have been modified but array_walk_recursive leaves
references.
This can cause trouble, eg you cant duplicate the original array
anymore. Look at following example
$data = array ('key1' = 'val1', array('key2' = 'val2'));
function foo($item, $key) {}; // dumb callback function
var_dump($data);
array_walk_recursive($data, 'foo');
$data2 = $data; // Duplicate array
$data2[0] = 'altered'; // Alter copy
var_dump($data);
var_dump($data2);
array(2) {
[key1]= string(4) val1
[0]= string(5) bingo
}
array(2) {
[key1]= string(4) val1
[0]= string(5) bingo
}
both $data and $data2 are altered;
Reproduce code:
---
$data = array ('key1' = 'val1', array('key2' = 'val2'));
function dumb($i, $k){}
var_dump($data);
array_walk_recursive($data,'foo');
// Double check the [0]=array(1) in actual result
var_dump($data);
Expected result:
Expected result:
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
Actual result:
--
Actual result:
--
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
array(2) {
[key1]= string(4) val1
[0]= array(1) {
[key2]= string(4) val2
}
}
--
Edit this bug report at http://bugs.php.net/?id=42850edit=1
#43847 [NEW]: Bug #34396 is not fixed - unset() un-declares a property
From: timshaw at mail dot usa dot com
Operating system: Win32
PHP version: 5.2.5
PHP Bug Type: Class/Object related
Bug description: Bug #34396 is not fixed - unset() un-declares a property
Description:
Shouldn't unset of a declared property still leave the property as a
declared property, so that the set overload will not later be used on it?
It is cool to unset things once their value becomes invalid to catch
errors using the invalid value. However, I could understand that this
overload problem is actually an undocumented feature if the person who
implemented overloads decided that everybody should be able to overload
everything, even declared properties, so this was put in to allow that
Too bad that doesn't accomodate those of us who don't want to use overloads
for everything, just some things.
Reproduce code:
---
?php
class c {
public $x ;
public function __set($nm, $val) { echo overloaded __set($nm, $val)
;\n ; }
public function __isset($nm) { echo overloaded __isset($nm) ;\n ; }
public function __unset($nm) { echo overloaded __unset($nm) ;\n ; }
}
$c = new c ;
echo Does not overload, just as expected and documented, because \$x is
declared property\n ;
echo \$c-x = , $c-x = 5, \n ;
echo Does not overload, just as expected, because \$x is declared
property\n ;
echo isset(\$c-x) = , isset($c-x)? 'True': 'False', \n ;
echo Does not use overload __unset, just as expected, because \$x is
declared property\n ;
echo unset(\$c-x)\n ;
unset($c-x) ;
echo Here's the problem- \$x is declared public property, but now it's
using overloaded set!\n ;
echo \$c-x = 5 ... ; $c-x = 5 ;
?
Expected result:
The overloaded ... should not appear because only the declared property
$x is used.
Actual result:
--
This does not call overload, just as expected and documented, because $x
is declared property
$c-x = 5
This does not call overload, just as expected, because $x is declared
property
isset($c-x) = True
This does not go though __unset, just as expected, because $x is declared
property
unset($c-x)
Here's the problem- $x is declared public property, but now it's using
overloaded set!
$c-x = 5 ... overloaded __set(x, 5) ;
--
Edit bug report at http://bugs.php.net/?id=43847edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43847r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43847r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43847r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43847r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43847r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43847r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43847r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43847r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43847r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43847r=support
Expected behavior:http://bugs.php.net/fix.php?id=43847r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43847r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43847r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43847r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43847r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43847r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43847r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43847r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43847r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43847r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43847r=mysqlcfg
#43497 [Asn]: OCI8 XML/getClobVal leaks UGA memory
ID: 43497
Updated by: [EMAIL PROTECTED]
Reported By: ghosh at q-one dot com
Status: Assigned
Bug Type: OCI8 related
Operating System: Linux 2.6.22-14-server
PHP Version: 5.2.5
Assigned To: sixd
New Comment:
An enhanced patch was sent to the bug filer and Tony on 8th Jan. I'm
still waiting for feedback . . .
Previous Comments:
[2008-01-06 23:17:34] ghosh at q-one dot com
Temporary LOBs are created in UGA memory. This is per-session, so
the leak appears on a per-session basis. Nevertheless this is a
problem, because PHP scripts dont necessarily have to run for a few
seconds. PHP is a full-featured scripting language and can also be
used from the command-line or to implement longer-running
import-scripts. Even if not, the limit is quickly reached, when
reading many rows like in my example.
[2008-01-06 20:42:52] [EMAIL PROTECTED]
What I don't understand: I thought OCI_RETURN_LOBS is just a short-
cut for those who don't want to write:
That's what I don't understand either: does the leak appear only on
per-session basis or Oracle doesn't free those LOBs at all?
If the leak is only per-session, then users are not supposed even to
notice it, since PHP requests are not supposed to take more than several
seconds.
[2007-12-29 22:37:21] ghosh at q-one dot com
Really great! Thanks a lot!! This patch works. What I don't understand:
I thought OCI_RETURN_LOBS is just a short-cut for those who don't want
to write:
$s=$result[0]-load();
$result[0]-free();
$result[0]=$s;
If you use OCI_RETURN_LOBS you dont want to care about lobs but get the
result as a string and forget about lobs altogether. So IMHO this should
work as well. My specific problem is solved though.
[2007-12-27 21:44:07] [EMAIL PROTECTED]
This is really an issue with temporary LOBS since getClobVal()
returns a temporary LOB.
There are two parts to the fix: changing the script and patching
the OCI8 extension. Also don't forget to apply the patch for
http://bugs.php.net/bug.php?id=42496
Please test this suggestion and report any issues.
Thanks to Krishna Shankar for the solution.
1. Change the test to get the results as LOBs, not as
strings. This allows the script to free temporary LOBs.
In the supplied testcase change:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt,
OCI_NUM+OCI_RETURN_LOBS))
;
to:
$query = select extract(xml, '/').getclobval() from ugatest;
$stmt = oci_parse($conn, $query);
if (oci_execute($stmt))
while ($result = oci_fetch_array($stmt, OCI_NUM)) {
// echo $result[0]-load(), \n; // do something with the
XML
$result[0]-free(); // free the temporary LOB
}
The connection must be open when LOB-free() is called, as the
underlying OCILobFreeTemporary() call does a roundtrip to the
database.
2. Patch oci8_lob.c. The change copies some LOB freeing code
from php_oci_lob_close() into php_oci_lob_free():
--- oci8_lob.c.orig2007-07-31 12:21:08.0 -0700
+++ oci8_lob.c2007-12-27 12:33:19.0 -0800
@@ -647,6 +647,9 @@
Close LOB descriptor and free associated resources */
void php_oci_lob_free (php_oci_descriptor *descriptor TSRMLS_DC)
{
+#ifdef HAVE_OCI8_TEMP_LOB
+int is_temporary;
+#endif
if (!descriptor || !descriptor-connection) {
return;
@@ -662,6 +665,40 @@
php_oci_lob_flush(descriptor, OCI_LOB_BUFFER_FREE TSRMLS_CC);
}
+#ifdef HAVE_OCI8_TEMP_LOB
+if (descriptor-type == OCI_DTYPE_LOB) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobIsTemporary,
+(
+descriptor-connection-env,
+descriptor-connection-err,
+descriptor-descriptor,
+is_temporary
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+php_oci_error(descriptor-connection-err,
descriptor-connection-errcode TSRMLS_CC);
+PHP_OCI_HANDLE_ERROR(descriptor-connection,
descriptor-connection-errcode);
+return 1;
+}
+if (is_temporary) {
+PHP_OCI_CALL_RETURN(descriptor-connection-errcode,
+OCILobFreeTemporary,
+(
+descriptor-connection-svc,
+descriptor-connection-err,
+descriptor-descriptor
+ )
+);
+if (descriptor-connection-errcode != OCI_SUCCESS) {
+
#43842 [NEW]: gerister_globals randomise switching value On/Off
From: dan at eskhosting dot com Operating system: Linux Red Hat ES 4 PHP version: 5.2.5 PHP Bug Type: *Configuration Issues Bug description: gerister_globals randomise switching value On/Off Description: Set up value for gerister_globals take a random effect. Reproduce code: --- php.ini: register_globals = Off .htaccess: php_flag register_globals On Expected result: register_globals On Actual result: -- ? phpinfo(); ? reports: register_globals On/Off - randomise! -- Edit bug report at http://bugs.php.net/?id=43842edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43842r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43842r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43842r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43842r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43842r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43842r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43842r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43842r=needscript Try newer version:http://bugs.php.net/fix.php?id=43842r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43842r=support Expected behavior:http://bugs.php.net/fix.php?id=43842r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43842r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43842r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43842r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43842r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43842r=dst IIS Stability:http://bugs.php.net/fix.php?id=43842r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43842r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43842r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43842r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43842r=mysqlcfg
#43848 [NEW]: Should be an option to disable echo when reading php://stdin
From: graced at wingsnw dot com Operating system: Irrelevant PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: Should be an option to disable echo when reading php://stdin Description: Short of using an experimental extension that's not likely to be available on a default install, there appears to be no way to disable/enable echoing of stdin content when reading it. A use case would be something like: ?php ob_implicit_flush(true); echo Please enter your password: ; // code to disable echo here $password = fgets(STDIN); // code to re-enable echo here. -- Edit bug report at http://bugs.php.net/?id=43848edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43848r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43848r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43848r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43848r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43848r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43848r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43848r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43848r=needscript Try newer version:http://bugs.php.net/fix.php?id=43848r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43848r=support Expected behavior:http://bugs.php.net/fix.php?id=43848r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43848r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43848r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43848r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43848r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43848r=dst IIS Stability:http://bugs.php.net/fix.php?id=43848r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43848r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43848r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43848r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43848r=mysqlcfg
#43812 [Asn]: 'password' parameter in my.cnf not honored even with mysqli_options()
ID: 43812 User updated by: graced at wingsnw dot com Reported By: graced at wingsnw dot com Status: Assigned Bug Type: MySQLi related Operating System: Debian lenny/sid PHP Version: 5.2.5 Assigned To: andrey New Comment: Clarification: Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6 'wadmin' was the username I was connecting with (I missed it when sanitizing my.cnf values), NOT my current login name (which is what PHP and mysql both default to otherwise). Just in case it matters. Previous Comments: [2008-01-11 03:32:02] graced at wingsnw dot com Description: my.cnf files allow the username/password/hostname and other connection information to be stored for later use. The Mysqli extension accepts a username from the file (overriding the default of the current login username) but not a password, thus it attempts to connect with no password even when a password is specified. The mysql command line client, when pointed at the file using --defaults-extra-file=path/to/file.cnf, successfully connects. Reproduce code: --- my.cnf contents: [client] host = localhost user = username password = topsecret PHP script: ?php error_reporting(E_ALL); $DB = mysqli_init(); $DB-options(MYSQLI_READ_DEFAULT_FILE, my.cnf); $DB-options(MYSQLI_READ_DEFAULT_GROUP, client); $DB-real_connect(); Expected result: A successful database connection. Actual result: -- Warning: mysqli::real_connect(): (28000/1045): Access denied for user 'wadmin'@'localhost' (using password: NO) in /home/.../- on line 6 -- Edit this bug report at http://bugs.php.net/?id=43812edit=1
#43849 [NEW]: date('YW', strtotime('2007-12-31')) return 200701
From: kiange at gmail dot com
Operating system: Ubuntu
PHP version: 5.2.5
PHP Bug Type: Date/time related
Bug description: date('YW', strtotime('2007-12-31')) return 200701
Description:
Enviornments:
PHP 5.2.3-1ubuntu6.2
Reproduce code:
---
echo date('YW', strtotime('2007-12-31'));
// return 200701, maybe 200801 according to the reference page
echo strftime(%Y%W,strtotime(2007-12-31));
// return 200753
Expected result:
200753 or 200801
Actual result:
--
200701
--
Edit bug report at http://bugs.php.net/?id=43849edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43849r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43849r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43849r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43849r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43849r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43849r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43849r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43849r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43849r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43849r=support
Expected behavior:http://bugs.php.net/fix.php?id=43849r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43849r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43849r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43849r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43849r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43849r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43849r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43849r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43849r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43849r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43849r=mysqlcfg
#43849 [Opn-Bgs]: date('YW', strtotime('2007-12-31')) return 200701
ID: 43849
Updated by: [EMAIL PROTECTED]
Reported By: kiange at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Ubuntu
PHP Version: 5.2.5
New Comment:
This is correct, the W shows the ISO week, which you need to match
against the ISO year specifier (o - small O). ISO Week 2008-01 goes
from Dec 31st to Jan 6th. This will return what you expect:
echo date('Yo', strtotime('2007-12-31')), \n;
strftime() would not be good to rely on, as the output might differ on
other operating systems.
Previous Comments:
[2008-01-15 06:18:31] kiange at gmail dot com
Description:
Enviornments:
PHP 5.2.3-1ubuntu6.2
Reproduce code:
---
echo date('YW', strtotime('2007-12-31'));
// return 200701, maybe 200801 according to the reference page
echo strftime(%Y%W,strtotime(2007-12-31));
// return 200753
Expected result:
200753 or 200801
Actual result:
--
200701
--
Edit this bug report at http://bugs.php.net/?id=43849edit=1
#43850 [NEW]: Error #43105 still exists! File close problem
From: dg at artegic dot de Operating system: Solaris 10 x86 PHP version: 5.2CVS-2008-01-15 (snap) PHP Bug Type: Apache2 related Bug description: Error #43105 still exists! File close problem Description: PHP (php5.2-200801141730) is still not closing open files, resulting in an email-related error after a while...as mentioned in error #43105: Could not execute mail delivery program '/usr/lib/sendmail -t -i' lsof -u daemon|grep httpd|wc -l 3937 ...still growing... Using Apache 2.2.6, mpm-worker, Solaris 10 x86. -- Edit bug report at http://bugs.php.net/?id=43850edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43850r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43850r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43850r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43850r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43850r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43850r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43850r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43850r=needscript Try newer version:http://bugs.php.net/fix.php?id=43850r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43850r=support Expected behavior:http://bugs.php.net/fix.php?id=43850r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43850r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43850r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43850r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43850r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43850r=dst IIS Stability:http://bugs.php.net/fix.php?id=43850r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43850r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43850r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43850r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43850r=mysqlcfg
#41608 [Fbk-Opn]: Apache crash because of script
ID: 41608
User updated by: aigors at inbox dot lv
Reported By: aigors at inbox dot lv
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows XP
PHP Version: 5.2.5
Assigned To: tony2001
New Comment:
Yes, it appears that bug is in the snapshots also.
Previous Comments:
[2008-01-14 22:26:03] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-12-18 09:47:50] aigors at inbox dot lv
Bug still exists in PHP 5.2.5.
[2007-06-06 08:35:53] [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.
[2007-06-06 07:44:20] aigors at inbox dot lv
Description:
Apache crash because of script containing set_error_handler function.
Reproduce code:
---
/***Main php file***/
?php
function MyErrorHandler($errno, $errstr, $errfile, $errline){
include_once('empty.php');
}
set_error_handler(MyErrorHandler);
include_once('blah.php');
echo('I am done');
?
/***blah.php file***/
?php
class Blah {
function foo($value, $classname) {
switch(strtolower($value['key'])) {
default: $x = new $classname;
}
}
}
?
/***empty.php file - no content***/
Expected result:
Should output I am done
Actual result:
--
Apache crash
--
Edit this bug report at http://bugs.php.net/?id=41608edit=1
