#47595 [NEW]: 'Include' outputs only included file.
From: stas87 at i dot ua Operating system: Vista PHP version: 5.2.9 PHP Bug Type: Output Control Bug description: 'Include' outputs only included file. Description: When i try to include file it outputs only that file without the page on which it was included Reproduce code: --- contents of file index.php ?php include./file.php; ? Expected result: contents of file index.php included contents of file ./file.php Actual result: -- included contents of file ./file.php -- Edit bug report at http://bugs.php.net/?id=47595edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47595r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47595r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47595r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47595r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47595r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47595r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47595r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47595r=needscript Try newer version: http://bugs.php.net/fix.php?id=47595r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47595r=support Expected behavior: http://bugs.php.net/fix.php?id=47595r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47595r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47595r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47595r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47595r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47595r=dst IIS Stability: http://bugs.php.net/fix.php?id=47595r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47595r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47595r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47595r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47595r=mysqlcfg
#47593 [Opn-Ver]: interface_exists() returns false when using absolute namespace path
ID: 47593
Updated by: ka...@php.net
Reported By: crystality at mail dot ru
-Status: Open
+Status: Verified
Bug Type: Class/Object related
Operating System: WinXpSP3
PHP Version: 5.3CVS-2009-03-08 (snap)
New Comment:
The following patch is just a port of the patch for class_exists() that
resolves the bug:
http://paste2.org/p/160586 - PHP_5_3
Previous Comments:
[2009-03-08 00:14:50] crystality at mail dot ru
Description:
Looks like this is the windows version of bug #46813.
Function interface_exists() used without autoloading returns FALSE
whith a fully qualified namespace.
class_exists() works ok. Well interface_exists() does work too but as
long as leading backslash isn't there or with autoloading enabled.
Reproduce code:
---
namespace interfaces;
interface debug{}
var_dump(interface_exists(\interfaces\debug, false)); // FALSE
Expected result:
True
Actual result:
--
False
--
Edit this bug report at http://bugs.php.net/?id=47593edit=1
#47595 [Opn-Csd]: 'Include' outputs only included file.
ID: 47595 User updated by: stas87 at i dot ua Reported By: stas87 at i dot ua -Status: Open +Status: Closed Bug Type: Output Control Operating System: Vista PHP Version: 5.2.9 New Comment: Sorry! The problem is solved! Forgot about mod_rewrite... Previous Comments: [2009-03-08 08:12:18] stas87 at i dot ua Description: When i try to include file it outputs only that file without the page on which it was included Reproduce code: --- contents of file index.php ?php include./file.php; ? Expected result: contents of file index.php included contents of file ./file.php Actual result: -- included contents of file ./file.php -- Edit this bug report at http://bugs.php.net/?id=47595edit=1
#47596 [NEW]: Bus error on parsing file
From: pahan at hubbitus dot info Operating system: Linux PHP version: 5.3.0beta1 PHP Bug Type: Reproducible crash Bug description: Bus error on parsing file Description: On particular file php always crashes with Bus Error. I'm try split file to get only sensible data, but I can't. ANY changes in it do predictable behavior and all works as expected. Even add/delete comment, any letter, space in any place... $ php test.bus.error.php Bus error Its contain many external dependencies, but it is absolutely unneeded for reproducibility: $ php -dinclude_path=: test.bus.error.php Bus error [pa...@x-www _SHARED_]$ ulimit -c unlimited [pa...@x-www _SHARED_]$ php -dinclude_path=/ test.bus.error.php Bus error (core dumped) This file is my working mess for test and sandboxing :), so, it is really not intended for any use outside and even any use except probes and examples. But as I can't even change 1 letter in it, I place it as is: http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Coredump file also available for download: http://ru.bir.ru/_temp/php- bugs/2/core.19581 Reproduce code: --- http://ru.bir.ru/_temp/php-bugs/2/test.bus.error.php.gz Sorry, I can't do that smaller. -- Edit bug report at http://bugs.php.net/?id=47596edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47596r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47596r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47596r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47596r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47596r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47596r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47596r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47596r=needscript Try newer version: http://bugs.php.net/fix.php?id=47596r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47596r=support Expected behavior: http://bugs.php.net/fix.php?id=47596r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47596r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47596r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47596r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47596r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47596r=dst IIS Stability: http://bugs.php.net/fix.php?id=47596r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47596r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47596r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47596r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47596r=mysqlcfg
#47598 [NEW]: FILTER_VALIDATE_EMAIL is locale aware
From: mikael at bluemist dot se
Operating system: Gentoo Slackware
PHP version: 5.2.9
PHP Bug Type: Filter related
Bug description: FILTER_VALIDATE_EMAIL is locale aware
Description:
FILTER_VALIDATE_EMAIL is locale aware and produces different results
depending on the locale set. Or more specific the \w escape sequence used
in the regular expression is locale aware.
From http://www.php.net/manual/en/regexp.reference.php:
The definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the fr (French) locale, some character codes greater than 128
are used for accented letters, and these are matched by \w.
Reproduce code:
---
setlocale(LC_CTYPE, 'C');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
setlocale(LC_CTYPE, 'sv_SE');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
string(15) å�...@example.com
Actual result:
--
string(15) å�...@example.com
string(15) å�...@example.com
--
Edit bug report at http://bugs.php.net/?id=47598edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47598r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47598r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47598r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47598r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47598r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47598r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47598r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47598r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47598r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47598r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47598r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47598r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47598r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47598r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47598r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47598r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47598r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47598r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47598r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47598r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47598r=mysqlcfg
#47598 [Opn]: FILTER_VALIDATE_EMAIL is locale aware
ID: 47598
User updated by: mikael at bluemist dot se
Reported By: mikael at bluemist dot se
Status: Open
Bug Type: Filter related
Operating System: Gentoo Slackware
PHP Version: 5.2.9
New Comment:
Sorry, expected result = actual result and actual = expected.
Previous Comments:
[2009-03-08 13:22:18] mikael at bluemist dot se
Description:
FILTER_VALIDATE_EMAIL is locale aware and produces different results
depending on the locale set. Or more specific the \w escape sequence
used in the regular expression is locale aware.
From http://www.php.net/manual/en/regexp.reference.php:
The definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the fr (French) locale, some character codes greater than
128 are used for accented letters, and these are matched by \w.
Reproduce code:
---
setlocale(LC_CTYPE, 'C');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
setlocale(LC_CTYPE, 'sv_SE');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
string(15) å�...@example.com
Actual result:
--
string(15) å�...@example.com
string(15) å�...@example.com
--
Edit this bug report at http://bugs.php.net/?id=47598edit=1
#47598 [Opn]: FILTER_VALIDATE_EMAIL is locale aware
ID: 47598
User updated by: mikael at bluemist dot se
Reported By: mikael at bluemist dot se
Status: Open
Bug Type: Filter related
Operating System: Gentoo Slackware
PHP Version: 5.2.9
New Comment:
After reading the RFC I realized characters like å ä ö (hex e5 e4 f6)
are not allowed (at least not unquoted). So the expected result should
be:
bool(false)
bool(false)
Previous Comments:
[2009-03-08 13:25:00] mikael at bluemist dot se
Sorry, expected result = actual result and actual = expected.
[2009-03-08 13:22:18] mikael at bluemist dot se
Description:
FILTER_VALIDATE_EMAIL is locale aware and produces different results
depending on the locale set. Or more specific the \w escape sequence
used in the regular expression is locale aware.
From http://www.php.net/manual/en/regexp.reference.php:
The definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the fr (French) locale, some character codes greater than
128 are used for accented letters, and these are matched by \w.
Reproduce code:
---
setlocale(LC_CTYPE, 'C');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
setlocale(LC_CTYPE, 'sv_SE');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
string(15) å�...@example.com
Actual result:
--
string(15) å�...@example.com
string(15) å�...@example.com
--
Edit this bug report at http://bugs.php.net/?id=47598edit=1
#47591 [Opn]: Unknown Whitespace being passed with value
ID: 47591 Updated by: ka...@php.net Reported By: diego at freagair dot com Status: Open Bug Type: Unknown/Other Function Operating System: Debian and FreeBSD PHP Version: 5.2.9 New Comment: What php code do you exactly use that is sent back to the browser? A small reproduce code would be needed to see if the bug is on php or browser level. Previous Comments: [2009-03-07 06:37:03] diego at freagair dot com Description: A user types in a color into an input box, it is then sent via ajax GET or POST to dynamically color any given DIV, via style.backgroundColor or color. More specific information about the issue located at the MSDN IE Forums: http://urloid.com/iebug2 It seems that the problem is generated by some whitespace in the PHP string 00380023 00380038 000a This whitespace problem occurs with (Debian) and (FreeBSD) Reproduce code: --- A white space is passed after any value, the error can be seen using any IE 6-8 http://89.233.173.91/bug/ Expected result: I would expect for the value to not contain any whitespace. Example: #333 is turned into #333 which causes errors with all Internet Explorer versions Actual result: -- Example at http://89.233.173.91/bug/ totally fails a very simple AJAX/ DOM script, because the PHP value contains a whitespace -- Edit this bug report at http://bugs.php.net/?id=47591edit=1
#47591 [Opn-Fbk]: Unknown Whitespace being passed with value
ID: 47591 Updated by: ka...@php.net Reported By: diego at freagair dot com -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Debian and FreeBSD PHP Version: 5.2.9 Previous Comments: [2009-03-08 14:18:16] ka...@php.net What php code do you exactly use that is sent back to the browser? A small reproduce code would be needed to see if the bug is on php or browser level. [2009-03-07 06:37:03] diego at freagair dot com Description: A user types in a color into an input box, it is then sent via ajax GET or POST to dynamically color any given DIV, via style.backgroundColor or color. More specific information about the issue located at the MSDN IE Forums: http://urloid.com/iebug2 It seems that the problem is generated by some whitespace in the PHP string 00380023 00380038 000a This whitespace problem occurs with (Debian) and (FreeBSD) Reproduce code: --- A white space is passed after any value, the error can be seen using any IE 6-8 http://89.233.173.91/bug/ Expected result: I would expect for the value to not contain any whitespace. Example: #333 is turned into #333 which causes errors with all Internet Explorer versions Actual result: -- Example at http://89.233.173.91/bug/ totally fails a very simple AJAX/ DOM script, because the PHP value contains a whitespace -- Edit this bug report at http://bugs.php.net/?id=47591edit=1
#47593 [Ver]: interface_exists() returns false when using absolute namespace path
ID: 47593
User updated by: crystality at mail dot ru
Reported By: crystality at mail dot ru
Status: Verified
Bug Type: Class/Object related
Operating System: WinXpSP3
PHP Version: 5.3CVS-2009-03-08 (snap)
New Comment:
When will a snapshot be available with the bug fixed?
Previous Comments:
[2009-03-08 08:21:35] ka...@php.net
The following patch is just a port of the patch for class_exists() that
resolves the bug:
http://paste2.org/p/160586 - PHP_5_3
[2009-03-08 00:14:50] crystality at mail dot ru
Description:
Looks like this is the windows version of bug #46813.
Function interface_exists() used without autoloading returns FALSE
whith a fully qualified namespace.
class_exists() works ok. Well interface_exists() does work too but as
long as leading backslash isn't there or with autoloading enabled.
Reproduce code:
---
namespace interfaces;
interface debug{}
var_dump(interface_exists(\interfaces\debug, false)); // FALSE
Expected result:
True
Actual result:
--
False
--
Edit this bug report at http://bugs.php.net/?id=47593edit=1
#47578 [Opn-Fbk]: mail no work OS 64bits
ID: 47578 Updated by: ka...@php.net Reported By: diegontche at boil dot com dot br -Status: Open +Status: Feedback Bug Type: Mail related Operating System: win32 only - Win 2003 r2 64bits PHP Version: 5.2.9 New Comment: Do you get a crash, and does the log return any information that might be useful to dig further into this issue? Previous Comments: [2009-03-05 18:52:01] diegontche at boil dot com dot br Yes .. SMTP does not work with 64bit For example ... if I use the windows 32 bit to activate the forum account, for example, works normally. Now with 64bit Windows not working to activate the SMTP mail. [2009-03-05 18:46:07] diegontche at boil dot com dot br Description: The function of the php mail is not working for 64bit OS. Not tls, not ssl. -- Edit this bug report at http://bugs.php.net/?id=47578edit=1
#47580 [Opn-Csd]: MSSQL: Changed database context to when connecting
ID: 47580
Updated by: ka...@php.net
Reported By: maxcamo at gmail dot com
-Status: Open
+Status: Closed
Bug Type: MSSQL related
Operating System: Win2003
PHP Version: 5.2CVS-2009-03-05 (snap)
New Comment:
This is an informal notice from dblib, Microsoft's TechNet have
information about this here:
http://technet.microsoft.com/en-us/library/aa275768(SQL.80).aspx
Previous Comments:
[2009-03-05 21:27:58] maxcamo at gmail dot com
Description:
Hi,
with MSSQL 2005,Apache 2.2.11 and PHP 5.2.6 i get this error when i
try to connect to the db
Changed database context to
The error raise up when I try to connect to the DB.
connections timeout are high
mssql.connect_timeout = 300
mssql.timeout = 300
It happen randomly, but more frequently when the site traffic si very
high
Reproduce code:
---
$Maxtries=60;
$delayMin=5;
$delayMax=10;
$delay=rand($delayMin,$delayMax);
$log_filename=conn_failed.log;
$tries=1;
$connDb = @mssql_connect($host, $user, $pwd));
if ($connDb)
mssql_select_db($db, $connDb);
while(!$connDb){
if ($tries=$Maxtries){
//echo Database failed to respond.;
$fp = fopen($log_filename,a+);
fputs($fp, gmdate(M d Y H:i:s) . : Errore Connessione \r\n);
fclose($fp);
exit;
}
usleep($delay*$tries);
$connDb = @mssql_connect($host, $user, $pwd));
if ($connDb)
mssql_select_db($db, $connDb);
$tries++;
}
if ($tries1){
$fp = fopen($log_filename,a+);
fputs($fp, gmdate(M d Y H:i:s) . :: Try:$tries ::
.$ServerName.:: .mssql_get_last_message(). :: . $pageName .
\r\n);
fclose($fp);
}
Expected result:
Db Connection
Actual result:
--
Mar 05 2009 21:08:19:: Try:2 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /index.html
Mar 05 2009 21:08:20:: Try:8 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /page2.html
Mar 05 2009 21:09:26:: Try:6 :: B-C2N1:: Il contesto di database è
stato sostituito con 'dbName'. :: /page3.html
--
Edit this bug report at http://bugs.php.net/?id=47580edit=1
#47599 [NEW]: znd_atoi() needs change for 64-bit support
From: Bjorn dot Wiberg at its dot uu dot se Operating system: All PHP version: 5.2.9 PHP Bug Type: Scripting Engine problem Bug description: znd_atoi() needs change for 64-bit support Description: External sources (http://turin.nss.udel.edu/wiki/dropbox/doku.php?id=documentation:large-files) indicate that zend_atoi() does not handle very large values correctly. External source supplies proposed fix (change to Zend/zend_operators.c). Reproduce code: --- Setting post_max_size 1M or upload_max_filesize 1M in php.ini. Expected result: Correct handling of very large memory values, e.g. 1M. Actual result: -- Limit maxes out at max value of 32 bits instead of specified value. -- Edit bug report at http://bugs.php.net/?id=47599edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47599r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47599r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47599r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47599r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47599r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47599r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47599r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47599r=needscript Try newer version: http://bugs.php.net/fix.php?id=47599r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47599r=support Expected behavior: http://bugs.php.net/fix.php?id=47599r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47599r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47599r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47599r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47599r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47599r=dst IIS Stability: http://bugs.php.net/fix.php?id=47599r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47599r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47599r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47599r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47599r=mysqlcfg
#47599 [Opn]: zend_atoi() needs change for 64-bit support
ID: 47599 User updated by: Bjorn dot Wiberg at its dot uu dot se -Summary: znd_atoi() needs change for 64-bit support Reported By: Bjorn dot Wiberg at its dot uu dot se Status: Open Bug Type: Scripting Engine problem Operating System: All PHP Version: 5.2.9 New Comment: Corrected summary Previous Comments: [2009-03-08 16:01:09] Bjorn dot Wiberg at its dot uu dot se Description: External sources (http://turin.nss.udel.edu/wiki/dropbox/doku.php?id=documentation:large-files) indicate that zend_atoi() does not handle very large values correctly. External source supplies proposed fix (change to Zend/zend_operators.c). Reproduce code: --- Setting post_max_size 1M or upload_max_filesize 1M in php.ini. Expected result: Correct handling of very large memory values, e.g. 1M. Actual result: -- Limit maxes out at max value of 32 bits instead of specified value. -- Edit this bug report at http://bugs.php.net/?id=47599edit=1
#47591 [Fbk-Opn]: Unknown Whitespace being passed with value
ID: 47591
User updated by: diego at freagair dot com
Reported By: diego at freagair dot com
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: Debian and FreeBSD
PHP Version: 5.2.9
New Comment:
Hello I have tried the following code below, but still seem to get the
extra white space. The values have been passed via AJAX POST and GET
but to no avail. All the commented code has also been used.
?php
//$paint = $_GET['paints'];
$paint = $_POST['paints'];
//PREVIEW COLOR
#echo trim($paint);
#echo '#AB1616';
$newStr = ereg_replace('[[:space:]]+', '', trim($paint));
echo $newStr;
#echo $paint;
echo trim($paint);
?
Previous Comments:
[2009-03-08 14:18:16] ka...@php.net
What php code do you exactly use that is sent back to the browser? A
small reproduce code would be needed to see if the bug is on php or
browser level.
[2009-03-07 06:37:03] diego at freagair dot com
Description:
A user types in a color into an input box, it is then sent via ajax
GET or POST
to dynamically color any given DIV, via style.backgroundColor or
color.
More specific information about the issue located at the MSDN IE
Forums: http://urloid.com/iebug2
It seems that the problem is generated by some whitespace in the PHP
string
00380023 00380038 000a
This whitespace problem occurs with (Debian) and (FreeBSD)
Reproduce code:
---
A white space is passed after any value, the error can be seen using
any IE 6-8 http://89.233.173.91/bug/
Expected result:
I would expect for the value to not contain any whitespace. Example:
#333 is turned into #333 which causes errors with all Internet
Explorer versions
Actual result:
--
Example at http://89.233.173.91/bug/ totally fails a very simple AJAX/
DOM script, because the PHP value contains a whitespace
--
Edit this bug report at http://bugs.php.net/?id=47591edit=1
#47598 [Opn-Asn]: FILTER_VALIDATE_EMAIL is locale aware
ID: 47598
Updated by: il...@php.net
Reported By: mikael at bluemist dot se
-Status: Open
+Status: Assigned
Bug Type: Filter related
Operating System: Gentoo Slackware
PHP Version: 5.2.9
-Assigned To:
+Assigned To: iliaa
Previous Comments:
[2009-03-08 13:55:27] mikael at bluemist dot se
After reading the RFC I realized characters like å ä ö (hex e5 e4 f6)
are not allowed (at least not unquoted). So the expected result should
be:
bool(false)
bool(false)
[2009-03-08 13:25:00] mikael at bluemist dot se
Sorry, expected result = actual result and actual = expected.
[2009-03-08 13:22:18] mikael at bluemist dot se
Description:
FILTER_VALIDATE_EMAIL is locale aware and produces different results
depending on the locale set. Or more specific the \w escape sequence
used in the regular expression is locale aware.
From http://www.php.net/manual/en/regexp.reference.php:
The definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the fr (French) locale, some character codes greater than
128 are used for accented letters, and these are matched by \w.
Reproduce code:
---
setlocale(LC_CTYPE, 'C');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
setlocale(LC_CTYPE, 'sv_SE');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
string(15) å�...@example.com
Actual result:
--
string(15) å�...@example.com
string(15) å�...@example.com
--
Edit this bug report at http://bugs.php.net/?id=47598edit=1
#47593 [Ver-Asn]: interface_exists() returns false when using absolute namespace path
ID: 47593
Updated by: fel...@php.net
Reported By: crystality at mail dot ru
-Status: Verified
+Status: Assigned
Bug Type: Class/Object related
Operating System: WinXpSP3
PHP Version: 5.3CVS-2009-03-08 (snap)
-Assigned To:
+Assigned To: felipe
Previous Comments:
[2009-03-08 14:19:05] crystality at mail dot ru
When will a snapshot be available with the bug fixed?
[2009-03-08 08:21:35] ka...@php.net
The following patch is just a port of the patch for class_exists() that
resolves the bug:
http://paste2.org/p/160586 - PHP_5_3
[2009-03-08 00:14:50] crystality at mail dot ru
Description:
Looks like this is the windows version of bug #46813.
Function interface_exists() used without autoloading returns FALSE
whith a fully qualified namespace.
class_exists() works ok. Well interface_exists() does work too but as
long as leading backslash isn't there or with autoloading enabled.
Reproduce code:
---
namespace interfaces;
interface debug{}
var_dump(interface_exists(\interfaces\debug, false)); // FALSE
Expected result:
True
Actual result:
--
False
--
Edit this bug report at http://bugs.php.net/?id=47593edit=1
#47593 [Asn-Csd]: interface_exists() returns false when using absolute namespace path
ID: 47593
Updated by: fel...@php.net
Reported By: crystality at mail dot ru
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: WinXpSP3
PHP Version: 5.3CVS-2009-03-08 (snap)
Assigned To: felipe
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:
[2009-03-08 14:19:05] crystality at mail dot ru
When will a snapshot be available with the bug fixed?
[2009-03-08 08:21:35] ka...@php.net
The following patch is just a port of the patch for class_exists() that
resolves the bug:
http://paste2.org/p/160586 - PHP_5_3
[2009-03-08 00:14:50] crystality at mail dot ru
Description:
Looks like this is the windows version of bug #46813.
Function interface_exists() used without autoloading returns FALSE
whith a fully qualified namespace.
class_exists() works ok. Well interface_exists() does work too but as
long as leading backslash isn't there or with autoloading enabled.
Reproduce code:
---
namespace interfaces;
interface debug{}
var_dump(interface_exists(\interfaces\debug, false)); // FALSE
Expected result:
True
Actual result:
--
False
--
Edit this bug report at http://bugs.php.net/?id=47593edit=1
#47598 [Asn-Csd]: FILTER_VALIDATE_EMAIL is locale aware
ID: 47598
Updated by: il...@php.net
Reported By: mikael at bluemist dot se
-Status: Assigned
+Status: Closed
Bug Type: Filter related
Operating System: Gentoo Slackware
PHP Version: 5.2.9
Assigned To: iliaa
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:
[2009-03-08 13:55:27] mikael at bluemist dot se
After reading the RFC I realized characters like å ä ö (hex e5 e4 f6)
are not allowed (at least not unquoted). So the expected result should
be:
bool(false)
bool(false)
[2009-03-08 13:25:00] mikael at bluemist dot se
Sorry, expected result = actual result and actual = expected.
[2009-03-08 13:22:18] mikael at bluemist dot se
Description:
FILTER_VALIDATE_EMAIL is locale aware and produces different results
depending on the locale set. Or more specific the \w escape sequence
used in the regular expression is locale aware.
From http://www.php.net/manual/en/regexp.reference.php:
The definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the fr (French) locale, some character codes greater than
128 are used for accented letters, and these are matched by \w.
Reproduce code:
---
setlocale(LC_CTYPE, 'C');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
setlocale(LC_CTYPE, 'sv_SE');
var_dump(filter_var('å�...@example.com', FILTER_VALIDATE_EMAIL));
Expected result:
bool(false)
string(15) å�...@example.com
Actual result:
--
string(15) å�...@example.com
string(15) å�...@example.com
--
Edit this bug report at http://bugs.php.net/?id=47598edit=1
#47600 [NEW]: ibase_connect core dump
From: janssensjohan at telenet dot be
Operating system: freebsd 7.1
PHP version: 5.2.9
PHP Bug Type: InterBase related
Bug description: ibase_connect core dump
Description:
ibase_connect gives a core dump.
With flamerobin I can connect and manipulate the database. ( from server
and even from XP client )
Reproduce code:
---
$connection =
ibase_connect('localhost:/usr/local/database/Universe.fdb','SYSDBA','xxx');
segmentation fault(core dumped)
Expected result:
a connection to the database.
Actual result:
--
a core dump which I can't read. On client side : an empty page
--
Edit bug report at http://bugs.php.net/?id=47600edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47600r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47600r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47600r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47600r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47600r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47600r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47600r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47600r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47600r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47600r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47600r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47600r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47600r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47600r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47600r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47600r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47600r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47600r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47600r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47600r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47600r=mysqlcfg
#47600 [Opn-Fbk]: ibase_connect core dump
ID: 47600
Updated by: fel...@php.net
Reported By: janssensjohan at telenet dot be
-Status: Open
+Status: Feedback
Bug Type: InterBase related
Operating System: freebsd 7.1
PHP Version: 5.2.9
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Previous Comments:
[2009-03-08 22:34:49] janssensjohan at telenet dot be
Description:
ibase_connect gives a core dump.
With flamerobin I can connect and manipulate the database. ( from
server and even from XP client )
Reproduce code:
---
$connection =
ibase_connect('localhost:/usr/local/database/Universe.fdb','SYSDBA','xxx');
segmentation fault(core dumped)
Expected result:
a connection to the database.
Actual result:
--
a core dump which I can't read. On client side : an empty page
--
Edit this bug report at http://bugs.php.net/?id=47600edit=1
#47601 [NEW]: defined() requires class
From: david at grudl dot com
Operating system:
PHP version: 5.2.9
PHP Bug Type: Class/Object related
Bug description: defined() requires class
Description:
Function defined() is very strict whether class constant is checking.
Non-declared (and not-autoloaded) class can be rather expressed as FALSE
than fatal error.
Reproduce code:
---
var_dump( defined('Test::VALUE') );
Expected result:
FALSE
Actual result:
--
Fatal error: Class 'Test' not found
--
Edit bug report at http://bugs.php.net/?id=47601edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47601r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47601r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47601r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47601r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47601r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47601r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47601r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47601r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47601r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47601r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47601r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47601r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47601r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47601r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47601r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47601r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47601r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47601r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47601r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47601r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47601r=mysqlcfg
#47601 [Opn-Fbk]: defined() requires class
ID: 47601
Updated by: scott...@php.net
Reported By: david at grudl dot com
-Status: Open
+Status: Feedback
Bug Type:Class/Object related
PHP Version: 5.2.9
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-03-08 22:55:57] david at grudl dot com
Description:
Function defined() is very strict whether class constant is checking.
Non-declared (and not-autoloaded) class can be rather expressed as FALSE
than fatal error.
Reproduce code:
---
var_dump( defined('Test::VALUE') );
Expected result:
FALSE
Actual result:
--
Fatal error: Class 'Test' not found
--
Edit this bug report at http://bugs.php.net/?id=47601edit=1
#47601 [Fbk-Opn]: defined() requires class
ID: 47601
User updated by: david at grudl dot com
Reported By: david at grudl dot com
-Status: Feedback
+Status: Open
Bug Type:Class/Object related
PHP Version: 5.2.9
New Comment:
It seems this bug exists only in 5.2.x branch (since 5.2.4 - 5.2.9).
PHP 5.3.0beta1 which is older than 5.2.9 is not affected.
Previous Comments:
[2009-03-09 00:10:45] scott...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-08 22:55:57] david at grudl dot com
Description:
Function defined() is very strict whether class constant is checking.
Non-declared (and not-autoloaded) class can be rather expressed as FALSE
than fatal error.
Reproduce code:
---
var_dump( defined('Test::VALUE') );
Expected result:
FALSE
Actual result:
--
Fatal error: Class 'Test' not found
--
Edit this bug report at http://bugs.php.net/?id=47601edit=1
