#47526 [NEW]: PCRE fails on Unicode surrogates
From: phpwnd at gmail dot com
Operating system:
PHP version: 5.3CVS-2009-02-28 (CVS)
PHP Bug Type: PCRE related
Bug description: PCRE fails on Unicode surrogates
Description:
According to http://docs.php.net/manual/en/regexp.reference.php PCRE
functions should be able to match surrogates in Unicode mode. However, it
is my understanding that surrogates are not allowed in UTF-8, which is the
encoding used by the Unicode mode. That would explain why preg_match() and
preg_replace() fail when operating on UTF-8-encoded surrogates.
Note that both functions fail in a different way. preg_match() returns 0
whereas preg_replace() returns NULL.
I'm not sure what the fix should be. Being able to match surrogates would
make my life easier, but if it's not valid UTF-8 then it might be more
consistent (albeit in a twisted way) to return NULL, as that's what PCRE
functions do on invalid UTF-8.
Reproduce code:
---
// \xED\xA0\x80 is character 0xD800 in UTF-8
var_dump(preg_match('#.#u', ".\xED\xA0\x80"));
var_dump(preg_replace('#\p{Cs}#u', '', ".\xED\xA0\x80"));
Expected result:
int(1)
string(1) "."
Actual result:
--
int(0)
NULL
--
Edit bug report at http://bugs.php.net/?id=47526&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47526&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47526&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47526&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47526&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47526&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47526&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47526&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47526&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47526&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47526&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47526&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47526&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47526&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47526&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47526&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47526&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47526&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47526&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47526&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47526&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47526&r=mysqlcfg
#47520 [Fbk->Opn]: PHP segfaulted in preg_replace on processing long string
ID: 47520
User updated by: pahan at hubbitus dot spb dot su
Reported By: pahan at hubbitus dot spb dot su
-Status: Feedback
+Status: Open
Bug Type: PCRE related
Operating System: Linux
PHP Version: 5.3.0beta1
New Comment:
Very apologize for mistake.
I'm fix rights now, please recheck.
Previous Comments:
[2009-02-28 01:19:21] fel...@php.net
I cannot download the coredump file: "You don't have permission to
access /_temp/php-pcre-bug/2/core.10135 on this server."
Can you give us a backtrace?
[2009-02-27 20:06:13] pahan at hubbitus dot spb dot su
I'm thrice check the previous reports about this issue. And what? All
closed as bogus, but segmentatoin fault still here! Where
solution/fix??? Even common workaraund of problem is absent.
Why it is bogus but not bug???
And also, please again read note: I use "Once-only subpattern", so,
this should prevent recursion as I can understand. Or not?
[2009-02-27 19:37:00] fel...@php.net
Please, check the previous reports about this issue:
http://bugs.php.net/search.php?search_for=&boolean=1&limit=10&order_by=id&direction=DESC&cmd=display&status=Bogus&bug_type%5B%5D=PCRE+related&php_os=&phpver=&assign=&author_email=&bug_age=0
http://docs.php.net/manual/en/pcre.configuration.php
[2009-02-27 11:13:58] pahan at hubbitus dot spb dot su
Description:
PHP segfaulted when I try replace in long string by next regexp:
'((?>(?:[^']|(?<=\\\)')*))'
Some comments to reproduce code comments to case 1 and 2 is clearly.
In case 3 and 4 I just run script several times, like (assume file
named test.php):
for (( i=100; i>0; i-- )) ; do echo -n $i: ; ./test.php ; done
Sample results of its run you may see here:
http://ru.bir.ru/_temp/php-pcre-bug/2/4965.log for 3 (files named by
length of tested string), and for 4 -
http://ru.bir.ru/_temp/php-pcre-bug/2/4967.log
Coredump may be downloaded here:
http://ru.bir.ru/_temp/php-pcre-bug/2/core.10135
Also, please note, I add construction (?> ... ) to speedup and
dissallow recursion, so, it is must be different from bugs
http://bugs.php.net/bug.php?id=27492 ,
http://bugs.php.net/bug.php?id=47376 ,
http://bugs.php.net/bug.php?id=47376 and
http://bugs.php.net/bug.php?id=27310 .
Reproduce code:
---
//1: Always "segmantation
fault"
//$cont = "'" . str_pad('', 4000, '-');>//2: "Never" (Is I can see in
1000 iterations) "segmantation fault"
//$cont = "'" . str_pad('', 4965, '-');>//3: Segfaulted from times to
times ~ 1-2 times from 100 executions
//$cont = "'" . str_pad('', 4967, '-');>//4: Segfaulted 50/50%
$reg = "#'((?>(?:[^']|(?<=\\\)')*))'#";
preg_replace($reg, '', $cont);
echo "OK\n";
?>
Expected result:
OK
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=47520&edit=1
#47504 [Opn->Bgs]: error "SQLSTATE[HY000]: General error: 2014" with sql comments
ID: 47504
Updated by: johan...@php.net
Reported By: admin at ifyouwantblood dot de
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Windows XP SP 3
PHP Version: 5.2.8
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
$pdo->query("INSERT INTO `test` (some) VALUES (''),
('1'); -- I AM AN SQL COMMENT, REMOVING ME WILL SOLVE THIS
PROBLEM");
Due to the ";" this is a multi-statement, executing two queries while
the second is only a comment. The second "result" can be accessed using
PDOStatement->nextRowset.
Previous Comments:
[2009-02-28 07:40:26] admin at ifyouwantblood dot de
also appears in 5.2.9
[2009-02-25 21:07:16] admin at ifyouwantblood dot de
Description:
i get this error with following code:
-
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other
unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you
may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000
#0 D:\_projects\web\1.php(13): PDO->query('INSERT INTO `te...')
#1 {main}
--
removing !SQL COMMENTS! will solve this. this only appears on windows
(XP), linux is fine. mysql version is 5.0.51a. latest XAMPP package was
used to test this (without modifications).
Reproduce code:
---
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$pdo->query(' CREATE TABLE IF NOT EXISTS `test` (
`some` VARCHAR( 100 ) NOT NULL
) ENGINE = INNODB ');
$pdo->query('SET TRANSACTION ISOLATION LEVEL SERIALIZABLE');
$pdo->query('START TRANSACTION');
$pdo->query("INSERT INTO `test` (some) VALUES (''),
('1'); -- I AM AN SQL COMMENT, REMOVING ME WILL SOLVE THIS
PROBLEM");
$pdo->query("INSERT INTO `test` (some) VALUES (''),
('1')");
$pdo->query('COMMIT');
function ehandler($exception)
{
echo ''."\r\n";
echo $exception->getMessage().' '.$exception->getCode();
echo "\r\n\r\n";
echo $exception->getTraceAsString();
echo '';
}
Expected result:
nothing
Actual result:
--
SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other
unbuffered queries are active. Consider using PDOStatement::fetchAll().
Alternatively, if your code is only ever going to run against mysql, you
may enable query buffering by setting the
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute. HY000
#0 D:\_projects\web\1.php(13): PDO->query('INSERT INTO `te...')
#1 {main}
--
Edit this bug report at http://bugs.php.net/?id=47504&edit=1
#47524 [Opn->Bgs]: register_func_function()
ID: 47524 Updated by: johan...@php.net Reported By: shaunspiller at gmail dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.9 New Comment: See http://pecl.php.net/package/intercept Previous Comments: [2009-02-27 21:26:47] shaunspiller at gmail dot com Description: Hi developers! I have a little feature suggestion for you... I've been developing a large proxy server-ish thingy using standalone PHP, with a basic "kernel" loop that handles deferred procedure calls and timers, and uses stream_select to handle incoming traffic for the network connections and dispatch them to their watcher objects. (It's co-operative multitasking!) The problem is the server is very, very complicated and difficult to debug. Functions nest very deeply. So I added a function called func_log, which calls PHP's very useful debug_backtrace() and uses it to fill a log file with a list of every single function call everywhere and (a cut-down listing of) their parameters. The log file soon becomes gigantic, but it's a phenomenally helpful and wonderful way to debug problems and get an overview of the code. I can review the entire file to find out exactly what goes wrong, and it helped locate a tricky couple of objects that were spuriously crashing PHP by recursively calling each other's Close functions(). (Running out of stack space is difficult to detect otherwise, since PHP logs no error before crashing.) So what's my suggestion? Well the problem with this type of debugging is the need to manually insert the call to the debugging/logging function at the start of every custom function (which I've done). It's an awkward hacky sort of solution, and the function is still called even when debugging/logging isn't wanted, so it always hurts performance. I thought about using declare(ticks) and register_tick_function() instead, but that can't be tuned to just function calls, so it would have to be called far too many times. So wouldn't it be wonderful to have some way to register a function to fire on every function call? E.g.,: bool register_func_function( callback function, [, int flags] ) "flags" would determine whether it should fire for just user functions, just built-in/extension functions, or both. Obviously it would have to disable as the callback is entered, and re-enable once it exits. Perhaps not the best name for it, but anyway, this would be useful for anyone and everyone trying to debug complex scripts. I'm not familiar with PHP's internals, but having a simple boolean to check if register_func_function is enabled shouldn't hurt performance at all really, right? That's my suggestion. Thanks very much for reading. Apologies if this has already been suggested, but I couldn't find it. -- Edit this bug report at http://bugs.php.net/?id=47524&edit=1
#47042 [Csd->Opn]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache
ID: 47042
User updated by: sriram dot natarajan at sun dot com
Reported By: sriram dot natarajan at sun dot com
-Status: Closed
+Status: Open
Bug Type: CGI related
Operating System: linux , solaris
-PHP Version: 5.2.8
+PHP Version: 5.2.9
New Comment:
Hi
php cgi module assumes that if redirect_uri is set , the request must
be from apache and throws away the script_name value and assigns
path_translated value to script name.
this is because, in cgi environment, apache sets the SCRIPT_NAME to
the location of the php-cgi binary and keeping the PATH_INFO variable to
point to the requested php script. this is very unique only to apache.
this crude test condition for apache is affecting sun web server
executing in fastcgi mode where in it looses the script_name value and
ends up returning with 'no input file specified'.
this happens only for sun web server and not for lighttpd because
lighttpd does not set redirect_uri when requested for index.php.
based on this analysis , earlier, i provided a patch to address this
issue . however, i overlooked the obvious and ended up breaking apache
in cgi mode.
because of this, a separate bug : http://bugs.php.net/bug.php?id=47149
has been filed and my suggested patch was reverted.
my sincere apology on providing this obviously broken patch and wasting
some of your time.
pl. find attached a below patch that should do the right thing.
what we want to do is
a) compare whether the script path is different from path translated
since we know that apache by default sets the script name to point to
the location of cgi binary and not the requested uri
[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}
if (env_path_translated != NULL &&
env_redirect_url != NULL &&
- orig_script_filename != NULL &&
script_path_translated != NULL) {
+ env_path_translated !=
script_path_translated &&
+ strcmp(env_path_translated,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
Previous Comments:
[2009-01-11 11:13:02] d...@php.net
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.
[2009-01-08 22:19:12] sriram dot natarajan at sun dot com
previous patch had whitespaces instead of tabs causing the patch to
appear distorted.
posting a same patch with this issue addressed
--- sapi/cgi/cgi_main.c.ORIGThu Jan 8 14:18:25 2009
+++ sapi/cgi/cgi_main.c Thu Jan 8 14:18:31 2009
@@ -960,7 +960,9 @@
TRANSLATE_SLASHES(env_document_root);
}
- if (env_path_translated != NULL &&
env_redirect_url != NULL) {
+ if (env_path_translated != NULL &&
env_redirect_url != NULL &&
+ orig_script_filename != NULL &&
script_path_translated != NULL &&
+ strcmp(orig_script_filename,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
[2009-01-08 20:06:25] sriram dot natarajan at sun dot com
here is the suggested patch to address this issue
--- sapi/cgi/cgi_main.c.ORIGWed Jan 7 07:10:14 2009
+++ sapi/cgi/cgi_main.c Wed Jan 7 19:37:21 2009
@@ -960,16 +960,18 @@
TRANSLATE_SLASHES(env_document_root);
}
- if (env_path_translated != NULL &&
env_redirect_url != NULL) {
- /*
- pretty much apache specific. If we
have a redirect_url
- then our script_filename and
script_name point to the
- php executable
- */
- script_path_translated =
env_path_translated;
- /* we correct SCRIPT_NAME now in case
we don't have PATH_INFO */
- env_sc
#15841 [Com]: CRLF to separate mail headers is incorrect
ID: 15841
Comment by: philipp dot kempgen at amooma dot de
Reported By: rha at juggernaut dot com dot au
Status: No Feedback
Bug Type: Mail related
Operating System: Linux
PHP Version: 4.1.2
Assigned To: yohgaki
New Comment:
Ok guys, if it's not mail() which is wrong then
it's a documentation problem.
---cut---
Note: If messages are not received, try using a LF (\n) only. Some poor
quality Unix mail transfer agents replace LF by CRLF automatically
(which leads to doubling CR if CRLF is used). This should be a last
resort, as it does not comply with » RFC 2822.
---cut---
This is _not_ about "poor quality" MTAs or a "last resort".
The note should read:
Note: mail() talks to the sendmail command on Unix/Linux which
expects line endings to be the platform's native line endings
which is LF (\n) only on Unix/Linux and CRLF (\r\n) on Windows.
The sendmail will replace LF (\n) by CRLF (\r\n) automatically
to comply with RFC 2822. Thus you should use the special PHP_EOL
constant to separate mail headers.
Previous Comments:
[2008-10-16 13:12:44] devnull at div dot org
I just had a little run-in with the postfix developers over at
postfix-users about this issue.
http://tech.groups.yahoo.com/group/postfix-users/message/244799
Quote:Wietse Venema:
>> Specifically, Postfix accepts local submissions in UNIX format
>> (LF) or MSDOS format (CRLF) format BUT YOU MIST NOT MIX FORMATS.
>
> So how does postfix determine what format you are using?
> Is there a way to explicitly tell it what to expect?
>
Postfix looks at the first input line. There currently is no
way to override this, so your best bet is to use the same line
terminator consistently (having a first line with CRLF might
work "best" for hybrid mail, but that behavior is not promised).
The current behavior originates from the time when binary transparency
was considered a good thing.
--
There seemed to me to be a marked hostility towards the idea of trying
to be helpful about this, but on the other hand I got the impression
they might not be hostile if someone offered a patch for a
SENDMAIL_EOF_COMPAT_MODE or similar.
Personally I am not much good at C, but the challenge is hereby issued
:)
[2007-02-21 09:16:42] m_alpka at tlen dot pl
I discovered another temporary solution. It's similar to @guy's but it
is not using additional scripts that have to be installed
(unix2dos,dos2unix). Also php didn't allow me to use piped sendmail in
sendmail_path (php.ini)
I'm using qmail.
---
cd /var/qmail/bin
cat > sendmailfix
#!/bin/sh
sed 's/^M$//' | /var/qmail/bin/sendmail ${1+"$@"}
[Ctrl+D]
chmod 555 sendmailfix
chgrp popuser sendmailfix
---
^M is a combination of [Ctrl+V, Ctrl+M]
Finally set the value of sendmail_path in php.ini to our script
---
sendmail_path = /var/qmail/bin/sendmailfix -t -i
[2007-02-07 10:05:27] tony2...@php.net
http://www.php.net/manual/en/reserved.constants.php
PHP_EOL (string)
Available since PHP 4.3.10 and PHP 5.0.2
[2007-02-07 09:55:43] bigtree at donotspam dot 29a dot nl
Might I suggest to add a platform-dependant PHP constant (for example
MAIL_HEADER_SEPARATOR) so we can use the mail() function with
platform-independent code?
The constant value would be '\n' on unix and '\r\n' on windows.
[2006-11-30 08:10:38] tech+ohtf dot cuc dot arg at onlineopinion dot
com dot au
The PHP documentation now asks for "\n" , which is correct for its
implementation in Unix systems, so the bug as originally reported is
solved. I can't comment on whether this change might have caused
problems in Windows, but I assume not.
Note: This was not just an issue with qmail; it also affected postfix's
implementation of 'sendmail'.
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/15841
--
Edit this bug report at http://bugs.php.net/?id=15841&edit=1
#47524 [Bgs]: register_func_function()
ID: 47524 User updated by: shaunspiller at gmail dot com Reported By: shaunspiller at gmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.9 New Comment: Ah, PECL, the great bitbucket in the PHP sky for extensions that folks don't know about, can't be used where compatibility is required, and Windows users have no hope of ever figuring out how to load. It doesn't seem to do a quarter of what I said either (hooking all functions whether specified or not, internal or user-land), so this certainly isn't "Bogus". Mark it "Wont fix" [sic] or put it back Open. Previous Comments: [2009-02-28 09:14:12] johan...@php.net See http://pecl.php.net/package/intercept [2009-02-27 21:26:47] shaunspiller at gmail dot com Description: Hi developers! I have a little feature suggestion for you... I've been developing a large proxy server-ish thingy using standalone PHP, with a basic "kernel" loop that handles deferred procedure calls and timers, and uses stream_select to handle incoming traffic for the network connections and dispatch them to their watcher objects. (It's co-operative multitasking!) The problem is the server is very, very complicated and difficult to debug. Functions nest very deeply. So I added a function called func_log, which calls PHP's very useful debug_backtrace() and uses it to fill a log file with a list of every single function call everywhere and (a cut-down listing of) their parameters. The log file soon becomes gigantic, but it's a phenomenally helpful and wonderful way to debug problems and get an overview of the code. I can review the entire file to find out exactly what goes wrong, and it helped locate a tricky couple of objects that were spuriously crashing PHP by recursively calling each other's Close functions(). (Running out of stack space is difficult to detect otherwise, since PHP logs no error before crashing.) So what's my suggestion? Well the problem with this type of debugging is the need to manually insert the call to the debugging/logging function at the start of every custom function (which I've done). It's an awkward hacky sort of solution, and the function is still called even when debugging/logging isn't wanted, so it always hurts performance. I thought about using declare(ticks) and register_tick_function() instead, but that can't be tuned to just function calls, so it would have to be called far too many times. So wouldn't it be wonderful to have some way to register a function to fire on every function call? E.g.,: bool register_func_function( callback function, [, int flags] ) "flags" would determine whether it should fire for just user functions, just built-in/extension functions, or both. Obviously it would have to disable as the callback is entered, and re-enable once it exits. Perhaps not the best name for it, but anyway, this would be useful for anyone and everyone trying to debug complex scripts. I'm not familiar with PHP's internals, but having a simple boolean to check if register_func_function is enabled shouldn't hurt performance at all really, right? That's my suggestion. Thanks very much for reading. Apologies if this has already been suggested, but I couldn't find it. -- Edit this bug report at http://bugs.php.net/?id=47524&edit=1
#47178 [Opn->Bgs]: Missing gzip headers in gzencode() output
ID: 47178 Updated by: m...@php.net Reported By: wharmby at uk dot ibm dot com -Status: Open +Status: Bogus Bug Type: Zlib Related Operating System: Windows XP PHP Version: 6CVS-2009-01-21 (snap) -Assigned To: +Assigned To: mike 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 Of course raw deflate encoded data does not have a gzip header. Previous Comments: [2009-01-21 11:41:35] wharmby at uk dot ibm dot com New tests dropped for gzencode dropped to php 5.2, 5.3 and 6. ext/zlib/tests/gzencode_variation2 ext/zlib/tests/gzencode_variation2-win32 in PHP 6 both tagged with XFAIL sections referencing this defect [2009-01-21 10:27:36] wharmby at uk dot ibm dot com Description: Missing gzip headers in output from gzencode() when FORCE_DEFLATE option specified. Problem persists for all values for $level argument. Problem seen at PHP 6 level only. I will be dropping some new PHPT shortly; the PHP 6 version will be tagged with XFAIL section because of this defect. Reproduce code: --- Expected result: Based on output for same script from 5.2/5.3 I expect something like: unicode(62) "1f8b0803f348cdc9c95708cf2fca49010056b1174a0b00" unicode(58) "1f8b0803789cf348cdc9c95708cf2fca490100180b041d" Actual result: -- unicode(62) "1f8b080bf348cdc9c95708cf2fca49010056b1174a0b00" unicode(38) "789cf348cdc9c95708cf2fca490100180b041d" -- Edit this bug report at http://bugs.php.net/?id=47178&edit=1
#44151 [Asn->NoF]: Errors not cleaned properly
ID: 44151
Updated by: dav...@php.net
Reported By: uwendel at mysql dot com
-Status: Assigned
+Status: No Feedback
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-02-18 (CVS)
Assigned To: davidc
Previous Comments:
[2008-12-17 18:05:38] dav...@php.net
Could you please test with the latest CVS or snapshot please? I have
made a few changes related to that lately and I'm wondering if that
could have fixed it.
Thanks,
[2008-02-18 16:51:11] uwendel at mysql dot com
Description:
According to the manual, PDO::errorInfo() returns the error information
about the "last operation performed by this database handle",
http://www.php.net/manual/en/function.PDO-errorInfo.php
What is PDO supposed to return if you perform two operations of which
the first fails and the second works fine, like this:
[1] THIS IS NO VALID SQL, I HOPE
[2] CREATE TABLE test(id int NOT NULL PRIMARY KEY, val VARCHAR(10), grp
VARCHAR(10))
Should errorInfo() return the error information from [1] or will the
error information be cleared prior to running [2]. In the latter case,
the user is given an additional easy way to check if an operation has
failed or not.
And the latter case (clear info before running [2]) is what I as the
desired behaviour.
Next question: which elements of the errorInfo() element shall be
reset? Currently it seems to me as if the SQLSTATE code is reset to
'0' but some drivers (e.g. PDO/MySQL, PDO/SQLlite, maybe more) do
not reset their driver specific fields. Haven't checked if that's an
issue caused by code from ext/pdo or from ext/pdo_mydriver.
Reproduce code:
---
--TEST--
PDO Common: PDO->errorInfo(), clear line after error
--SKIPIF--
--FILE--
exec('THIS IS NO VALID SQL, I HOPE');
var_dump($db->errorInfo());
var_dump($db->errorCode());
$db->exec('CREATE TABLE test(id int NOT NULL PRIMARY KEY, val
VARCHAR(10), grp VARCHAR(10))');
var_dump($db->errorInfo());
var_dump($db->errorCode());
print "done!";
?>
--EXPECTF--
array(3) {
[0]=>
string(5) "%s"
[1]=>
int(%d)
[2]=>
string(%d) "%s"
}
string(5) "%s"
array(3) {
[0]=>
string(5) "0"
[1]=>
NULL
[2]=>
NULL
}
string(5) "0"
done!
Expected result:
see above
Actual result:
--
see above
--
Edit this bug report at http://bugs.php.net/?id=44151&edit=1
#47530 [NEW]: Importing objects into document fragments creates bogus "default" namespace
From: sgunderson at bigfoot dot com
Operating system: Debian
PHP version: 5.2.9
PHP Bug Type: DOM XML related
Bug description: Importing objects into document fragments creates bogus
"default" namespace
Description:
Hi,
When I import a DOM node via a document fragment, suddenly a "default"
namespace comes out of nowhere (and it's really hard to remove, short of
making my own cloneNode() simulation stripping it).
IIRC PHP4 got this right (although it had lots of other issues), and all
other languages I've tested in (Perl, Python, Ruby) do as well. Note that
the code below doesn't strictly need importNode(), but I cannot really do
with cloneNode() in the real code (it's vastly simplified).
Note: On the surface, this appears to be the same bug as #46185, but I
tested 5.3 CVS (as of 2009-02-28) and it's still there.
Reproduce code:
---
loadXML('');
$root = $doc->documentElement;
$elem = $root->firstChild;
$frag = $doc->createDocumentFragment();
$frag->appendChild($doc->importNode($elem));
$root->appendChild($frag);
print $doc->saveXML();
?>
Expected result:
Actual result:
--
--
Edit bug report at http://bugs.php.net/?id=47530&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47530&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47530&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47530&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47530&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47530&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47530&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47530&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47530&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47530&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47530&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47530&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47530&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47530&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47530&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47530&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47530&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47530&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47530&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47530&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47530&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47530&r=mysqlcfg
#47531 [NEW]: No way of removing redundant xmlns: declarations
From: sgunderson at bigfoot dot com
Operating system: Debian
PHP version: 5.3CVS-2009-02-28 (snap)
PHP Bug Type: DOM XML related
Bug description: No way of removing redundant xmlns: declarations
Description:
There seems to be no good way of manipulating XML namespace declarations
at all. In particular, they never get garbage collected in any way, and you
cannot remove them manually, so they will stick around forever unless you
create a new one. My typical use case is shown in the reproduce code below
(although the element will typically have child elements).
Since 5.3 (bug #38949) it seems I can getAttribute() the xmlns element,
but still not remove it it any reasonable way (and it should really just
disappear by itself; it does in other languages).
Reproduce code:
---
loadXML('');
$root = $doc->documentElement;
$elem = $root->firstChild;
$elem->removeAttributeNode($elem->attributes->item(0));
print $doc->saveXML();
?>
Expected result:
Actual result:
--
--
Edit bug report at http://bugs.php.net/?id=47531&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47531&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47531&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47531&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47531&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47531&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47531&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47531&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47531&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47531&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47531&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47531&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47531&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47531&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47531&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47531&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47531&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47531&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47531&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47531&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47531&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47531&r=mysqlcfg
#47532 [NEW]: DOMAttribute value getter and setter do not escape equally
From: sgunderson at bigfoot dot com
Operating system: Debian
PHP version: 5.3CVS-2009-02-28 (snap)
PHP Bug Type: DOM XML related
Bug description: DOMAttribute value getter and setter do not escape equally
Description:
When you fetch the "value" field of a DOMAttribute, it seems to unescape
any HTML (or perhaps XML?) entities present. However, when you set it, it
does not get escaped. In other words, if you do "$attr->value =
$attr->value" (which really should be a no-op!) as in the example below,
you will get errors if it happened to contain &.
Verified with PHP 5.2.6 and 5.3.0 snap (2008-02-28).
Reproduce code:
---
loadXML('');
$elem = $doc->documentElement->firstChild;
$attr = $doc->createAttribute("foo");
$attr->value = "foo&bar";
$attr->value = $attr->value;
$elem->appendChild($attr);
print $doc->saveXML();
?>
Expected result:
Actual result:
--
Warning: main(): unterminated entity reference bar in
/home/sesse/test3.php on line 8
--
Edit bug report at http://bugs.php.net/?id=47532&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47532&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47532&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47532&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47532&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47532&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47532&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47532&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47532&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47532&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47532&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47532&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47532&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47532&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47532&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47532&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47532&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47532&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47532&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47532&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47532&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47532&r=mysqlcfg
#47521 [Opn->Bgs]: In jquery ajax. When I send variables thru 'get' it works but not on 'post'
ID: 47521 Updated by: ka...@php.net Reported By: mandar dot dhotre at yahoo dot co dot in -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows PHP Version: 5.2CVS-2009-02-27 (snap) New Comment: Check the jQuery documentation, this is not a bug related to php Previous Comments: [2009-02-27 16:04:27] mandar dot dhotre at yahoo dot co dot in Description: I am using jquery ajax. When I send the variables thru get method it works but wen I send them thru POST and try to catch them using REQUEST or POST it doesnt work. I need to use POST only as m using it for username-password. -- Edit this bug report at http://bugs.php.net/?id=47521&edit=1
#47513 [Com]: when using date, H shows 01 instead of 00
ID: 47513
Comment by: usrhlp at yahoo dot com
Reported By: usrhlp at yahoo dot com
Status: Open
Bug Type: Date/time related
Operating System: Debian
PHP Version: 5.2.8
New Comment:
Thank you, GMDATE has fixed the issue!!
Please close this bug as erroneous.
Previous Comments:
[2009-02-27 21:59:07] shaunspiller at gmail dot com
It's the time zone on your machine. The number "5" refers to the time
January 1 1970 @ 00:00:05 UTC, which date() will format as something
different if you're in CET, etc.
Use the format codes 'O' or 'P' to show the timezone offset.
If you want it always fixed at UTC, use gmdate() instead of date().
Or use date_default_timezone_set first. E.g.,
if (version_compare(PHP_VERSION, '5.1.0', '>=')) {
date_default_timezone_set('UTC');
}
[2009-02-26 23:07:57] usrhlp at yahoo dot com
I just tried it on another server I have with php 5.2.6 and i get this
result
18:00.01
18:00.10
18:01.40
18:16.40
20:46.40
21:46.40
07:46.40
12:46.40
That has totally thrown me off.
[2009-02-26 22:59:30] usrhlp at yahoo dot com
Description:
I am probably doing something wrong but I cannot for the life of me
figure out what it is.
I am trying to convert a small number to 24 hour time format. For
example I'm parsing the number 5 through the date function and I am
receiving the answer
01:00.05
I checked the PHP documentation and it shows as this for date()
H 24-hour format of an hour with leading zeros00 through 23
According to the documentation 00 is a possible output of the H
formatting within date and should be what is coming out.
Reproduce code:
---
echo(date("H:i.s" ,1));
echo(date("H:i.s" ,10));
echo(date("H:i.s" ,100));
echo(date("H:i.s" ,1000));
echo(date("H:i.s" ,1));
echo(date("H:i.s" ,10));
echo(date("H:i.s" ,100));
echo(date("H:i.s" ,1000));
Expected result:
time: 00:00.01
time: 00:00.10
time: 00:01.40
time: 00:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
Actual result:
--
time: 01:00.01
time: 01:00.10
time: 01:01.40
time: 01:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
--
Edit this bug report at http://bugs.php.net/?id=47513&edit=1
#47513 [Opn->Bgs]: when using date, H shows 01 instead of 00
ID: 47513
User updated by: usrhlp at yahoo dot com
Reported By: usrhlp at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Debian
PHP Version: 5.2.8
New Comment:
use GMdate instead of date.
Previous Comments:
[2009-02-28 20:29:22] usrhlp at yahoo dot com
Thank you, GMDATE has fixed the issue!!
Please close this bug as erroneous.
[2009-02-27 21:59:07] shaunspiller at gmail dot com
It's the time zone on your machine. The number "5" refers to the time
January 1 1970 @ 00:00:05 UTC, which date() will format as something
different if you're in CET, etc.
Use the format codes 'O' or 'P' to show the timezone offset.
If you want it always fixed at UTC, use gmdate() instead of date().
Or use date_default_timezone_set first. E.g.,
if (version_compare(PHP_VERSION, '5.1.0', '>=')) {
date_default_timezone_set('UTC');
}
[2009-02-26 23:07:57] usrhlp at yahoo dot com
I just tried it on another server I have with php 5.2.6 and i get this
result
18:00.01
18:00.10
18:01.40
18:16.40
20:46.40
21:46.40
07:46.40
12:46.40
That has totally thrown me off.
[2009-02-26 22:59:30] usrhlp at yahoo dot com
Description:
I am probably doing something wrong but I cannot for the life of me
figure out what it is.
I am trying to convert a small number to 24 hour time format. For
example I'm parsing the number 5 through the date function and I am
receiving the answer
01:00.05
I checked the PHP documentation and it shows as this for date()
H 24-hour format of an hour with leading zeros00 through 23
According to the documentation 00 is a possible output of the H
formatting within date and should be what is coming out.
Reproduce code:
---
echo(date("H:i.s" ,1));
echo(date("H:i.s" ,10));
echo(date("H:i.s" ,100));
echo(date("H:i.s" ,1000));
echo(date("H:i.s" ,1));
echo(date("H:i.s" ,10));
echo(date("H:i.s" ,100));
echo(date("H:i.s" ,1000));
Expected result:
time: 00:00.01
time: 00:00.10
time: 00:01.40
time: 00:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
Actual result:
--
time: 01:00.01
time: 01:00.10
time: 01:01.40
time: 01:16.40
time: 03:46.40
time: 04:46.40
time: 14:46.40
time: 18:46.40
--
Edit this bug report at http://bugs.php.net/?id=47513&edit=1
#47533 [NEW]: php crash when it is compile without --enable-debug
From: pioklo at serveradmin dot pl
Operating system: debian 5.0
PHP version: 5.2.9
PHP Bug Type: Reproducible crash
Bug description: php crash when it is compile without --enable-debug
Description:
Hello There !
I have a serious problem with the 5.2.9 version and earlier versions of
PHP.
I am running lighttpd with php as fastcgi.
php crash time to time when it is compilde without --enable-debug.
I have busy site about 20 mln page views per day.
I have made a backtrace
Core was generated by `/usr/local/bin/php-cgi'.
Program terminated with signal 11, Segmentation fault.
[New process 4363]
#0 zend_mm_remove_from_free_list (heap=0xcf8300, mm_block=0xfd94b0) at
/root/php-5.2.9/Zend/zend_alloc.c:832
832 if (UNEXPECTED(prev->next_free_block != mm_block)
|| UNEXPECTED(next->prev_free_block != mm_block)) {
(gdb) bt
#0 zend_mm_remove_from_free_list (heap=0xcf8300, mm_block=0xfd94b0) at
/root/php-5.2.9/Zend/zend_alloc.c:832
#1 0x00709c88 in _zend_mm_free_int (heap=0xcf8300, p=0xfd94c0) at
/root/php-5.2.9/Zend/zend_alloc.c:1979
#2 0x00719df4 in shutdown_executor () at
/root/php-5.2.9/Zend/zend_execute_API.c:313
#3 0x00724893 in zend_deactivate () at
/root/php-5.2.9/Zend/zend.c:860
#4 0x006e263c in php_request_shutdown (dummy=) at /root/php-5.2.9/main/main.c:1492
#5 0x00798062 in main (argc=1, argv=0x7fff2f0df458) at
/root/php-5.2.9/sapi/cgi/cgi_main.c:2053
The same script is working fine when php was compiled with --enable-debug
AND when user_id is filled not NULL then is NO crash
We have use Zend as framework so the code when
Reproduce code:
---
case 'votes':
$oVote = PS_Vote_UserProfile::factory(
PS_Auth::getInstance()->getProperty( 'user_id' ) );
and the function getProperty()
public function getProperty( $sName )
{
return $this->getUser()->$sName;
}
Actual result:
--
segfault
--
Edit bug report at http://bugs.php.net/?id=47533&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47533&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47533&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47533&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47533&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47533&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47533&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47533&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47533&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47533&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47533&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47533&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47533&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47533&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47533&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47533&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47533&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47533&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47533&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47533&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47533&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47533&r=mysqlcfg
#47370 [Asn]: array_unique has backward compatibility problem, and SORT_REGULAR is confusing
ID: 47370
User updated by: for-bugs at hnw dot jp
Reported By: for-bugs at hnw dot jp
Status: Assigned
Bug Type: Arrays related
Operating System: *
-PHP Version: 5.2.9RC1
+PHP Version: 5.2.9
Assigned To: andrei
New Comment:
Hi, Andrei. Here's another terrible example.
string(2) "10"
[1]=>
string(3) "1az"
[2]=>
string(3) "1e1"
}
array(2) {
[0]=>
string(3) "1e1"
[2]=>
string(3) "1az"
}
The array $a and $b have same 3 elements with different ordering.
Although, two array_unique() returns different result.
First array_unique() returns 3 elements in spite of the fact that "10"
equals "1e1" with ==.
In fact, the two arrays are both sorted about SORT_REGULAR. Because
"10" < "1az" , "1az" < "1e1" and "1e1"=="10". Sorting with SORT_REGULAR
is not stable, and unique element is not always in neighbor.
This behavior is not obvious for almost all PHP programmer. You should
explain the detail of your function in reference manual.
Previous Comments:
[2009-02-14 08:28:18] for-bugs at hnw dot jp
OK, you think comparing elements as string is harmful, doesn't you?
Then, how about array_diff() or array_intersect()? They compare array
elements with string representation. Isn't it harmful?
[2009-02-14 08:22:26] moriyo...@php.net
This was not discussed, and thus no bogus thing.
[2009-02-13 22:27:35] and...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The slight BC breakage is negligible compared to the benefits of
getting it to work properly.
[2009-02-13 01:53:09] for-bugs at hnw dot jp
Thank you so much. The snapshot returns same result to PHP 5.2.8 with
reproduce code. Such as:
array(2) {
[0]=>
int(0)
[1]=>
string(0) ""
}
array(2) {
[0]=>
string(0) ""
[1]=>
string(1) "0"
}
[2009-02-12 18:58:34] moriyo...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
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/47370
--
Edit this bug report at http://bugs.php.net/?id=47370&edit=1
#47534 [NEW]: RecursiveDirectoryIterator::current() always returns SplFileInfo
From: david at ethos-consulting dot com Operating system: MacOS X 10.5.6 PHP version: 5.2.9 PHP Bug Type: SPL related Bug description: RecursiveDirectoryIterator::current() always returns SplFileInfo Description: The return value for RecursiveDirectoryIterator::current() is _always_ SplFileInfo, which isn't as expected and is less useful than the behavior in previous versions within the 5.2.x branch. At least one other programmer has submitted this as a bug, as well (see #37530), however he was dismissed with the standard RTFM boilerplate. This is a flaw in the behavior of the class, IMO, however, since there's no way to _disable_ the class from returning SplFileInfo. The SPL documentation briefly refers to a flag that can be passed to __construct() named "CURRENT_AS_FILEINFO", which would indicate to me that the default behavior for the class is to return something _other_ than SplFileInfo for current(). The docs seem to back that up, listing the variable behavior of current() to alternate between getFilename() and getFileInfo(). However, the class consistently returns SplFileInfo, regardless of the flags provided to the constructor. Reproduce code: --- http://bugs.php.net/?id=47534&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47534&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47534&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47534&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47534&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47534&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47534&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47534&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47534&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47534&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47534&r=support Expected behavior: http://bugs.php.net/fix.php?id=47534&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47534&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47534&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47534&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47534&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47534&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47534&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47534&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47534&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47534&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47534&r=mysqlcfg
#47509 [Opn->Fbk]: Round problem
ID: 47509
Updated by: ka...@php.net
Reported By: home dot mail at inbox dot ru
-Status: Open
+Status: Feedback
Bug Type: Math related
Operating System: Win
PHP Version: 5.2.8
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Please describe the issue you are experincing abit better
Previous Comments:
[2009-02-26 11:32:56] home dot mail at inbox dot ru
Description:
why round() return illegal result?
Reproduce code:
---
while($row = odbc_fetch_array($q)){
extract($row);
print_r($row);
var_dump($ISHSALDO);
echo round($ISHSALDO, 2);
echo "\n";
}
Expected result:
Array
(
[NAM] =>
[GOR] =>
[V_KUL] => ø
[ULL] =>
[DOM] =>
[IDM] =>
[KVR] =>
[DOG] => 1998
[ISHSALDO] => 290.000
[NACH] => 295.000
[OPLATA] => 290.000
[TEL] => 000
)
string(7) "290.000"
290
Actual result:
--
Array
(
[NAM] =>
[GOR] =>
[V_KUL] => ø
[ULL] =>
[DOM] =>
[IDM] =>
[KVR] =>
[DOG] => 1998
[ISHSALDO] => 290.000
[NACH] => 295.000
[OPLATA] => 290.000
[TEL] => 000
)
string(7) "290.000"
28:
--
Edit this bug report at http://bugs.php.net/?id=47509&edit=1
#44420 [Opn->NoF]: upload_tmp_dir directive in php.ini ignored for file uploads
ID: 44420 Updated by: ka...@php.net Reported By: jturner at paycomonline dot com -Status: Open +Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.2.5 New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2008-11-18 00:38:41] ka...@php.net I'm not totally sure, but I think its somehow related to the path like: X:\dir~1\..., can you try without using the ~N syntax? [2008-11-13 15:39:59] alb dot amati at tiscali dot it It seems I have the same problem. Exactly the same configuration. Any workaround? Thanx Alb [2008-03-13 13:17:04] jturner at paycomonline dot com Yes, the IWAM and IUSR accounts both have read, write, and list folder contents rights in the ACL for that directory. I forgot to mention yesterday that I have PHP set to run as an ISAPI module. [2008-03-13 12:19:49] j...@php.net Is that path writable/readable by the user with which the webserver runs as? [2008-03-12 16:36:02] jturner at paycomonline dot com Description: The upload_tmp_dir directive is set in the php.ini to "C:\DOCUME~1\ADMINI~1.HQ-\LOCALS~1\Temp\php\upload" and shows up as such when running phpinfo(). However, when I try to upload a file it fails, and print_r($_FILES) reports that "tmp_name" is set to "C:\WINDOWS\TEMP\[filename]". It appears that the directive is being ignored in favor of the environment variable, which is contrary to the documentation. PHP5.2.5/IIS6.0/Windows Server 2003 A search of the bug database turned up bug #39451 which appears to be similar but was marked as fixed in 5.2.1RC3. -- Edit this bug report at http://bugs.php.net/?id=44420&edit=1
