Bug #64864 [Opn->Csd]: shuffle() and array_push are broken with PDO.
Edit report at https://bugs.php.net/bug.php?id=64864&edit=1
ID: 64864
User updated by:mail at kinesis dot me
Reported by:mail at kinesis dot me
Summary:shuffle() and array_push are broken with PDO.
-Status: Open
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Ubuntu Linux 13.04 x64
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
I was seeding the random number generator with 0.
Previous Comments:
[2013-05-16 20:32:52] mail at kinesis dot me
Description:
$this->answer['id'] is always at the end, when it is supposed to be shuffled.
This looks like a bug to me. array_rand() will not work either.
$this->current_set=$this->dbh->query("SELECT DISTINCT id FROM
$game_type WHERE id != '".(string)$this->answer['id']."' ORDER BY rand() LIMIT
2;")->fetchAll(PDO::FETCH_COLUMN);
//$this->complete_set=""
//echo "Current set separated by commas is
".implode(",",$this->current_set->fetchAll(PDO::FETCH_COLUMN)) +
$this->answer['id']."";
//$this->current_set=$this->current_set->fetchAll(PDO::FETCH_COLUMN);
array_push($this->current_set,$this->answer['id']);
explode(",",$this->current_set);
shuffle($this->current_set); // $this->answer['id'] is always at
the end?
print_r($this->current_set);
print_r($this->answer['id']);
var_dump($this->current_set, 3);
Test script:
---
$this->current_set=$this->dbh->query("SELECT DISTINCT id FROM
$game_type WHERE id != '".(string)$this->answer['id']."' ORDER BY rand() LIMIT
2;")->fetchAll(PDO::FETCH_COLUMN);
//$this->complete_set=""
//echo "Current set separated by commas is
".implode(",",$this->current_set->fetchAll(PDO::FETCH_COLUMN)) +
$this->answer['id']."";
//$this->current_set=$this->current_set->fetchAll(PDO::FETCH_COLUMN);
array_push($this->current_set,$this->answer['id']);
explode(",",$this->current_set);
shuffle($this->current_set); // $this->answer['id'] is always at
the end?
print_r($this->current_set);
print_r($this->answer['id']);
var_dump($this->current_set, 3);
Expected result:
I expect the array '$this->current_set' to have the value of $this->answer
pushed towards the end. Then I shuffle() or array_rand() the array, but
$this->answer always appears as the third element of the array no matter what I
do.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64864&edit=1
[PHP-BUG] Bug #64864 [NEW]: shuffle() and array_push are broken with PDO.
From: mail at kinesis dot me
Operating system: Ubuntu Linux 13.04 x64
PHP version: 5.4.15
Package: PDO related
Bug Type: Bug
Bug description:shuffle() and array_push are broken with PDO.
Description:
$this->answer['id'] is always at the end, when it is supposed to be
shuffled.
This looks like a bug to me. array_rand() will not work either.
$this->current_set=$this->dbh->query("SELECT DISTINCT id FROM
$game_type WHERE id != '".(string)$this->answer['id']."' ORDER BY rand()
LIMIT 2;")->fetchAll(PDO::FETCH_COLUMN);
//$this->complete_set=""
//echo "Current set separated by commas is
".implode(",",$this->current_set->fetchAll(PDO::FETCH_COLUMN)) +
$this->answer['id']."";
//$this->current_set=$this->current_set->fetchAll(PDO::FETCH_COLUMN);
array_push($this->current_set,$this->answer['id']);
explode(",",$this->current_set);
shuffle($this->current_set); // $this->answer['id'] is always
at the end?
print_r($this->current_set);
print_r($this->answer['id']);
var_dump($this->current_set, 3);
Test script:
---
$this->current_set=$this->dbh->query("SELECT DISTINCT id FROM
$game_type WHERE id != '".(string)$this->answer['id']."' ORDER BY rand()
LIMIT 2;")->fetchAll(PDO::FETCH_COLUMN);
//$this->complete_set=""
//echo "Current set separated by commas is
".implode(",",$this->current_set->fetchAll(PDO::FETCH_COLUMN)) +
$this->answer['id']."";
//$this->current_set=$this->current_set->fetchAll(PDO::FETCH_COLUMN);
array_push($this->current_set,$this->answer['id']);
explode(",",$this->current_set);
shuffle($this->current_set); // $this->answer['id'] is always
at the end?
print_r($this->current_set);
print_r($this->answer['id']);
var_dump($this->current_set, 3);
Expected result:
I expect the array '$this->current_set' to have the value of $this->answer
pushed towards the end. Then I shuffle() or array_rand() the array, but
$this->answer always appears as the third element of the array no matter
what I do.
--
Edit bug report at https://bugs.php.net/bug.php?id=64864&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64864&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64864&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64864&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64864&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64864&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64864&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64864&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64864&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64864&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64864&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64864&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64864&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64864&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64864&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64864&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64864&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64864&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64864&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64864&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64864&r=mysqlcfg
Req #40296 [Com]: "unless" control structure
Edit report at https://bugs.php.net/bug.php?id=40296&edit=1
ID: 40296
Comment by: charlie at gorichanaz dot com
Reported by:mail at tobyinkster dot co dot uk
Summary:"unless" control structure
Status: Wont fix
Type: Feature/Change Request
Package:*General Issues
Operating System: All
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
Well, I maintain I would love to see this control structure implemented. I
understand a non English speaker might not have the same level of understanding
of the word "unless" as a native English speaker, but you can say the same of
any other keyword in PHP or any other programming language written in English,
and I fail to see how that is a valid argument against its inclusion.
Previous Comments:
[2013-05-16 19:45:59] freshtuneage at gmail dot com
Ha ha, PHP lusers. "We don't want this feature because it is too
complicated for our training wheel-restricted users." What a
bunch of simplistic dolts. When you're ready to move forward into
the brave new world of the 1990's, let the rest of us know.
[2013-02-20 18:36:04] email at philsturgeon dot co dot uk
It looks like this conversation dried up after the rather out-of-context
confusion
over unless somehow meaning "more".
Can we move past that please, as it's a ridiculous non-issue.
[2012-07-30 15:09:00] email at philsturgeon dot co dot uk
Rasmus: toby was not suggesting that "uniqid" is the opposite of "iqid", he is
saying that you can have "un" at the start of a function or keyword without it
automatically flipping the meaning of the next few letters and confusing people
-
as you suggested in your comment yesterday.
In neither situation does "un" switch the meaning of the following letters, so
if
it is ok for one function/keyword it should be ok for another, right?
I don't want to argue, I just want to make sure people are clear. I would hate
to
see this conversation derailed by confusion or people loudly agreeing.
[2012-07-30 15:00:31] ras...@php.net
Now you are just being silly. "uniqid" is "unique id" from the latin root "uni"
meaning one or singular. Makes perfect sense . It isn't "un" anything.
[2012-07-30 13:19:47] mail at tobyinkster dot co dot uk
FWIW, while Perl does allow
unless (foo) { bar }
else { baz }
I've never seen it in the wild. I've only ever seen unless used without any
trailing else conditions. (And although Perl syntax allows else following
unless, it explicitly disallows elsif following unless.) I'd be perfectly happy
for PHP to forbid both elseif and else after unless.
> It also isn't a very common feature in other languages
Latin had "nisi". Modern languages derived from Latin are all the poorer for
having lost this concept.
> It is an odd word that essentially means not-if even though
> it logically should be equivalent to "more" as in the
> opposite of "more" would be "less" and sticking "un" in
> front of it suddenly completely changes the meaning entirely.
By that logic, uniqid() should return the opposite of the iqid() function.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=40296
--
Edit this bug report at https://bugs.php.net/bug.php?id=40296&edit=1
Req #40296 [Com]: "unless" control structure
Edit report at https://bugs.php.net/bug.php?id=40296&edit=1
ID: 40296
Comment by: freshtuneage at gmail dot com
Reported by:mail at tobyinkster dot co dot uk
Summary:"unless" control structure
Status: Wont fix
Type: Feature/Change Request
Package:*General Issues
Operating System: All
PHP Version:5.2.0
Block user comment: N
Private report: N
New Comment:
Ha ha, PHP lusers. "We don't want this feature because it is too
complicated for our training wheel-restricted users." What a
bunch of simplistic dolts. When you're ready to move forward into
the brave new world of the 1990's, let the rest of us know.
Previous Comments:
[2013-02-20 18:36:04] email at philsturgeon dot co dot uk
It looks like this conversation dried up after the rather out-of-context
confusion
over unless somehow meaning "more".
Can we move past that please, as it's a ridiculous non-issue.
[2012-07-30 15:09:00] email at philsturgeon dot co dot uk
Rasmus: toby was not suggesting that "uniqid" is the opposite of "iqid", he is
saying that you can have "un" at the start of a function or keyword without it
automatically flipping the meaning of the next few letters and confusing people
-
as you suggested in your comment yesterday.
In neither situation does "un" switch the meaning of the following letters, so
if
it is ok for one function/keyword it should be ok for another, right?
I don't want to argue, I just want to make sure people are clear. I would hate
to
see this conversation derailed by confusion or people loudly agreeing.
[2012-07-30 15:00:31] ras...@php.net
Now you are just being silly. "uniqid" is "unique id" from the latin root "uni"
meaning one or singular. Makes perfect sense . It isn't "un" anything.
[2012-07-30 13:19:47] mail at tobyinkster dot co dot uk
FWIW, while Perl does allow
unless (foo) { bar }
else { baz }
I've never seen it in the wild. I've only ever seen unless used without any
trailing else conditions. (And although Perl syntax allows else following
unless, it explicitly disallows elsif following unless.) I'd be perfectly happy
for PHP to forbid both elseif and else after unless.
> It also isn't a very common feature in other languages
Latin had "nisi". Modern languages derived from Latin are all the poorer for
having lost this concept.
> It is an odd word that essentially means not-if even though
> it logically should be equivalent to "more" as in the
> opposite of "more" would be "less" and sticking "un" in
> front of it suddenly completely changes the meaning entirely.
By that logic, uniqid() should return the opposite of the iqid() function.
[2012-07-29 21:42:28] email at philsturgeon dot co dot uk
In regards to double negatives, I agree. If I see a developer do this unless a
!=
7 then I would block their PR and instantly go and have a talk with them about
writing sane code.
As for else it really shouldn't be used that much but it should be possible.
unless (foo === 'bar') {
// do something
}
else {
// do something else
}
Is that really a confusion?
Unlesselse might become a dog though, not sure about that:
unless (foo === 'bar') {
// do something
}
unlesselse (foo === 'baz') {
// do something
}
else {
// do something else
}
At that point you'd just want to be using a switch, but that is the same for
if's.
As I said unless should not really use an else, otherwise you'd be better off
just
using an if and swapping it around, but having it doesn't hurt.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=40296
--
Edit this bug report at https://bugs.php.net/bug.php?id=40296&edit=1
Bug #64815 [Opn->Fbk]: Rendering some image broken
Edit report at https://bugs.php.net/bug.php?id=64815&edit=1 ID: 64815 Updated by: ahar...@php.net Reported by:adrianbjones at gmail dot com Summary:Rendering some image broken -Status: Open +Status: Feedback Type: Bug Package:GD related Operating System: Debian PHP Version:5.4.15 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. A reproduction script using GD directly would be extremely helpful, along with the configure lines used both in PHP 5.4.14 and 5.4.15 and any difference in libpng versions, please. Previous Comments: [2013-05-10 18:07:37] adrianbjones at gmail dot com Description: I am using PEAR Image_Canvas to dynamically generate some images. The same script has worked from PHP 4.x all the way through to 5.4.14. Basically the script layers several transparent png files together to make a combined image I just upgraded to 5.4.15 and the images are no longing rendering properly. Certain elements are replaced by solid rectangles and others have a variety of color changes. It seems like it might be a transparency issue with PNG files, but not sure. Reverting to 5.4.14 instantly fixes the images. -- Edit this bug report at https://bugs.php.net/bug.php?id=64815&edit=1
Bug #52974 [NoF->Opn]: Calendar Extension jewish.c
Edit report at https://bugs.php.net/bug.php?id=52974&edit=1 ID: 52974 Updated by: ahar...@php.net Reported by:xiaomao5 at live dot com Summary:Calendar Extension jewish.c -Status: No Feedback +Status: Open Type: Bug Package:Compile Failure Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Reopening. GBK seems to be a common theme here, and line 326 includes ISO-8859-8 encoded Hebrew which iconv suggests is invalid in GBK. Previous Comments: [2013-05-10 09:13:02] zhaoyong dot lc at gmail dot com I find this problem too in PHP 5.3.17, I want to complie PHP in Windows but error "jewish.c(324) : error C2001" is throwed out. My OS is Windows 7 with GBK character set and Compiler is Visual Studio 2008. It also can't be corrent by changing encoding and character set. [2013-02-18 00:34:30] php-bugs at lists dot php dot net 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. [2011-03-21 06:17:30] zhangsilly at gmail dot com this problem is still in PHP 5.3.6. The same problem is in ext/standard/browscap.c, in the line 61. My OS is Windows 7 & Windows XP.Compiler is Visual Studio 2008.But , I think is not matter with compiler, when i use Editplus to view these files, Thy cann't show correct,not matter i choose the encoding with ANSI/GBK or UTF-8. [2010-10-03 10:43:07] cataphr...@php.net Please give information such as: * The compiler * The actual error message, including the line wherein it occurred * Your codepage (type chcp in the command prompt before compiling PHP from there) * The procedure you used to compile PHP * Anything else that you may find relevant to the resolution of this problem In future, please provide all the possibly relevant information in the bug report. See also http://bugs.php.net/how-to-report.php [2010-10-03 03:47:21] xiaomao5 at live dot com Found at php-5.3.3.tar.bz2 no changes have been done since extarcting The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=52974 -- Edit this bug report at https://bugs.php.net/bug.php?id=52974&edit=1
Bug #64833 [Com]: ext/sockets/sendrecvmsg.c related compilation errors
Edit report at https://bugs.php.net/bug.php?id=64833&edit=1 ID: 64833 Comment by: clicky at erebot dot net Reported by:clicky at erebot dot net Summary:ext/sockets/sendrecvmsg.c related compilation errors Status: Assigned Type: Bug Package:Compile Failure Operating System: Debian Squeeze PHP Version:5.5.0RC1 Assigned To:cataphract Block user comment: N Private report: N New Comment: Adding to my initial report. Compiling with ./configure --disable-all --enable-sockets also triggers this issue, although with a different output: /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1288:31: error: invalid use of undefined type âstruct in6_pktinfoâ /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1289:37: error: invalid use of undefined type âstruct in6_pktinfoâ /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1307:29: error: invalid use of undefined type âstruct ucredâ /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1307:29: error: initializer element is not constant /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1307:29: error: (near initialization for âdescriptors_ucred[0].field_offsetâ) /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1308:29: error: invalid use of undefined type âstruct ucredâ /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1308:29: error: initializer element is not constant /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1308:29: error: (near initialization for âdescriptors_ucred[1].field_offsetâ) /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1310:29: error: invalid use of undefined type âstruct ucredâ /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1310:29: error: initializer element is not constant /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/conversions.c:1310:29: error: (near initialization for âdescriptors_ucred[2].field_offsetâ) make: *** [ext/sockets/conversions.lo] Error 1 Previous Comments: [2013-05-13 21:49:36] clicky at erebot dot net Description: While trying to build PHP 5.5.0RC1 under Debian Squeeze, the following compilation errors were triggered. I think this may be related to this commit that introduced support for SCM_CREDENTIALS and other goodies in the sockets extension recently: http://git.php.net/?p=php-src.git;a=commitdiff;h=a85d7f28f69fbc522ed90aee1926d3733be7620d Also, please note that the manpage for UNIX sockets states that "struct ucred" (which is used in the code) is only defined when the _GNU_SOURCE macro is defined since glibc 2.8 [1]. This may also be the reason why the build fails (Debian Squeeze uses libc6-2.13 [2]). Other projects have been impacted by this issue too [3]. [1] http://manpages.ubuntu.com/manpages/karmic/en/man7/unix.7.html [2] http://packages.debian.org/wheezy/libc6 [3] http://sourceforge.net/p/wide-dhcpv6/bugs/29/ (also contains link to a glibc commit that changed some of the structs like in6_pktinfo to be macro-guarded). Test script: --- './configure' \ '--enable-debug' \ '--disable-all' \ '--disable-short-tags' \ '--disable-sigchild' \ '--with-layout=GNU' \ '--with-regex' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath=shared' \ '--with-bz2=shared' \ '--enable-calendar=shared' \ '--with-gettext=shared' \ '--enable-mbstring=shared' \ '--enable-pcntl=shared' \ '--enable-sockets=shared' \ '--with-pdo-sqlite' \ '--enable-sysvmsg=shared' \ '--enable-sysvsem=shared' \ '--enable-sysvshm=shared' \ '--with-xsl=shared' \ '--with-iconv=shared' \ '--enable-zip=shared' \ '--enable-posix=shared' \ '--enable-libxml=shared' \ '--enable-dom=shared' \ '--enable-xml=shared' \ '--enable-xmlreader=shared' \ '--enable-xmlwriter=shared' \ '--enable-tokenizer=shared' \ '--enable-pdo' \ '--enable-ctype=shared' \ '--enable-json=shared' \ '--enable-session=shared' \ '--enable-soap=shared' \ '--enable-simplexml=shared' \ '--enable-hash' \ '--enable-intl=shared' \ '--enable-phar=shared' \ '--with-sqlite3' \ '--with-mysql=shared,mysqlnd' \ '--with-mysqli=shared,mysqlnd' \ '--with-pdo-mysql=shared,mysqlnd' \ '--prefix=/home/qa/phpfarm/inst/php-5.5.0RC1-debug' \ '--exec-prefix=/home/qa/phpfarm/inst/php-5.5.0RC1-debug' \ '--without-pear' \ '--enable-cgi' \ '--enable-cli' \ '--enable-fpm' \ "$@" (but could probably be reduced to just ./configure --disable-all --enable-sockets=shared) Expected result: PHP should build without any compilation error. Actual result: -- /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c: In function âinit_ancillary_registryâ: /home/qa/phpfarm/src/php-5.5.0RC1-debug/ext/sockets/sendrecvmsg.c:109:2: error: invalid app
Bug #54538 [Com]: setlocale() interferes with NumberFormatter class
Edit report at https://bugs.php.net/bug.php?id=54538&edit=1
ID: 54538
Comment by: hariombalhara at gmail dot com
Reported by:davidkarlin at gmail dot com
Summary:setlocale() interferes with NumberFormatter class
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: OS X
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
thanks for the workaround. It worked well for me :) Here is the exact problem I
was facing
http://stackoverflow.com/questions/16334752/numberformatterformatcurrency-return-
nan-with-fr-fr-utf-8
Previous Comments:
[2011-07-26 13:01:36] radek dot dvorak at gmail dot com
I have observed a workaround. Setting LC_MESSAGES does not affect
NumberFormatter
and is sufficient for gettext translations at the same time.
[2011-04-16 16:52:30] cataphr...@php.net
PHP passes the correct value to ICU, namely it passes the expected double to
unum_formatDouble. This is likely an ICU defect. See:
http://bugs.icu-project.org/trac/ticket/8214
[2011-04-15 13:34:02] davidkarlin at gmail dot com
Sorry - I typed the wrong lines in the expected and actual results. Should be
"123.456,789" in both cases. But you get the idea...
[2011-04-15 13:32:41] davidkarlin at gmail dot com
Description:
---
>From manual page: http://www.php.net/class.numberformatter
---
When I have my locale set to 'en' with setlocale(), the NumberFormatter class
works just fine.
If I set the locale to, for example, 'fr_FR', the NumberFormatter class fails,
giving a 'NaN' result. This is irrespective of the fact that the setlocale()
function has clearly worked, as evidenced by gettext() working just fine.
I can't see any reason why the setlocale function should have anything to do
with
the operation of NumberFormatter: this isn't documented, and I'm explicitly
passing the locale I want to use in the parameter.
Using 5.3.5 (the most recent available through MacPorts)
Test script:
---
setlocale(LC_ALL, 'en');
$nf = new NumberFormatter('de_DE',NumberFormatter::DECIMAL);
print $nf->format(123456.789); // Outputs the correct answer 123.456,789
print "\n";
setlocale(LC_ALL, 'fr_FR');
$nf = new NumberFormatter('de_DE',NumberFormatter::DECIMAL);
print $nf->format(123456.789); // Outputs NaN
Expected result:
123456.789
123456.789
Actual result:
--
123456.789
NaN
--
Edit this bug report at https://bugs.php.net/bug.php?id=54538&edit=1
Bug #61390 [NoF->Opn]: Segfault occurs in simple flatfile test
Edit report at https://bugs.php.net/bug.php?id=61390&edit=1 ID: 61390 Updated by: ahar...@php.net Reported by:cjashfor at linux dot vnet dot ibm dot com Summary:Segfault occurs in simple flatfile test -Status: No Feedback +Status: Open Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.4.0 -Assigned To:dmitry +Assigned To: Block user comment: N Private report: N New Comment: Reopening, per bug #51278. Previous Comments: [2013-05-16 19:02:45] ahar...@php.net Related To: Bug #51278 [2013-02-18 19:04:48] cjashfor at linux dot vnet dot ibm dot com This bug should be re-opened because it hasn't been fixed. I don't know what the correct solution is in the implementation, but the bug shouldn't be closed till it's resolved. [2013-02-18 00:35:45] php-bugs at lists dot php dot net 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. [2012-05-21 13:54:41] dmi...@php.net why dba_close() closes a persistent resource? In comparison mysql_close() doesn't close connection opened using mysql_pconnect() and as result ext/mysql doesn't make this problem. BTW: ZE resources have refcount, but unfortunately it couldn't help in this case. [2012-03-31 01:37:19] yohg...@php.net The needs of resource reference counter is pointed out by Stefan Esser many years ago. I'm not sure who is the right person, but I'll assign this to Dmitry for now so that someone could take care of this. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61390 -- Edit this bug report at https://bugs.php.net/bug.php?id=61390&edit=1
Bug #51278 [Opn->Dup]: Crash when using reopened persistent connection after one resource closed
Edit report at https://bugs.php.net/bug.php?id=51278&edit=1 ID: 51278 Updated by: ahar...@php.net Reported by:christopher dot jones at oraclel dot com Summary:Crash when using reopened persistent connection after one resource closed -Status: Open +Status: Duplicate Type: Bug Package:DBM/DBA related Operating System: Linux PHP Version:5.3SVN-2010-03-12 (SVN) Block user comment: N Private report: N New Comment: I'll close this in favour of bug #61390, since it has more detail. I'll reopen that one momentarily. I don't see assigning a bug to someone at random as being particularly helpful (as #61390 shows, in fact): what's really needed here is a patch or pull request. If someone with php-src karma knowledgeable about dba had time to fix this, I'm sure they would. Previous Comments: [2013-05-06 23:32:49] cjashfor at linux dot vnet dot ibm dot com Shouldn't someone at least be assigned to fix this bug? I reported what appears to be an identical bug - 61390 - and it was closed after just a small amount of discussion from the developers, followed by inactivity. [2010-03-12 01:17:26] christopher dot jones at oraclel dot com Description: Do two dba_popen() calls using the same file. Close one resource with dba_close(). Then do a dba_fetch on the still open resource. This results in a crash in flatfile_findkey() with a NULL dba pointer. Program received signal SIGSEGV, Segmentation fault. 0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173 (gdb) bt #0 0x0817c3b4 in flatfile_findkey (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:173 #1 0x0817bfaa in flatfile_fetch (dba=0x0, key_datum=...) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/libflatfile/flatfile.c:91 #2 0x0817a671 in dba_fetch_flatfile (info=0x89abb20, key=0x897b2bc "key1", keylen=4, skip=0, newlen=0xbfffd348) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/ext/dba/dba_flatfile.c:70 #3 0x0817871b in zif_dba_fetch (ht=2, return_value=0x897a638, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/ext/dba/dba.c:1025 #4 0x0844ccf0 in zend_do_fcall_common_helper_SPEC (execute_data=0x89abcc8) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:313 #5 0x084507ae in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x89abcc8) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend_vm_execute.h:1603 #6 0x0844c38d in execute (op_array=0x897ac98) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/Zend/zend_vm_execute.h:104 #7 0x0841ff12 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/Zend/zend.c:1194 #8 0x083b6c16 in php_execute_script (primary_file=0xb7c4) at /home/cjones/phpsrc/php/php-src/branches/PHP_5_3/main/main.c:2260 #9 0x084dd733 in main (argc=2, argv=0xb954) at /home/cjones/phpsrc/php/php- src/branches/PHP_5_3/sapi/cli/php_cli.c:1192 Test script: --- See ext/dba/tests/dba015.phpt -- Edit this bug report at https://bugs.php.net/bug.php?id=51278&edit=1
Bug #64863 [Asn->Nab]: PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build
Edit report at https://bugs.php.net/bug.php?id=64863&edit=1 ID: 64863 Updated by: paj...@php.net Reported by:vr...@php.net Summary:PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build -Status: Assigned +Status: Not a bug Type: Bug Package:*Compile Issues Operating System: Windows 64bit PHP Version:5.5.0RC1 -Assigned To:szarkos +Assigned To:pajoye Block user comment: N Private report: N New Comment: This is expected. long is always 32bit, no matter the architecture. The actual full 64bit support requires much more deep changes, won't happen in 5.5, but most likely in next major (f.e. 5+1). Previous Comments: [2013-05-16 18:21:36] vr...@php.net Steve, can you please take a look? [2013-05-16 18:20:01] vr...@php.net Description: I want to work with DB bigint data type without troubles, I want to call mysql_insert_id() safely. Also some problems in Google Code Jam require 8 bytes int and it's very hard to solve them with 4 bytes int because BC is too slow. I know that this might be by design but it is a bad design. Especially given that Linux 64 bits builds have 8 bytes int. Also the main advantage of 64 bits is to be able to use these 64 bits. Test script: --- https://bugs.php.net/bug.php?id=64863&edit=1
[PHP-BUG] Bug #64863 [NEW]: PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build
From: vrana Operating system: Windows 64bit PHP version: 5.5.0RC1 Package: *Compile Issues Bug Type: Bug Bug description:PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build Description: I want to work with DB bigint data type without troubles, I want to call mysql_insert_id() safely. Also some problems in Google Code Jam require 8 bytes int and it's very hard to solve them with 4 bytes int because BC is too slow. I know that this might be by design but it is a bad design. Especially given that Linux 64 bits builds have 8 bytes int. Also the main advantage of 64 bits is to be able to use these 64 bits. Test script: --- https://bugs.php.net/bug.php?id=64863&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64863&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64863&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64863&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64863&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64863&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64863&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64863&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64863&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64863&r=support Expected behavior: https://bugs.php.net/fix.php?id=64863&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64863&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64863&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64863&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64863&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64863&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64863&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64863&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64863&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64863&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64863&r=mysqlcfg
Bug #64863 [Opn]: PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build
Edit report at https://bugs.php.net/bug.php?id=64863&edit=1 ID: 64863 Updated by: vr...@php.net Reported by:vr...@php.net Summary:PHP_INT_SIZE is 4 instead of 8 on 64bit Windows build Status: Open Type: Bug Package:*Compile Issues Operating System: Windows 64bit PHP Version:5.5.0RC1 -Assigned To: +Assigned To:szarkos Block user comment: N Private report: N New Comment: Steve, can you please take a look? Previous Comments: [2013-05-16 18:20:01] vr...@php.net Description: I want to work with DB bigint data type without troubles, I want to call mysql_insert_id() safely. Also some problems in Google Code Jam require 8 bytes int and it's very hard to solve them with 4 bytes int because BC is too slow. I know that this might be by design but it is a bad design. Especially given that Linux 64 bits builds have 8 bytes int. Also the main advantage of 64 bits is to be able to use these 64 bits. Test script: --- https://bugs.php.net/bug.php?id=64863&edit=1
[PHP-BUG] Bug #64862 [NEW]: imagecopyresized doesn't handle negative width/height
From: matteosistisette at gmail dot com Operating system: PHP version: 5.3.25 Package: GD related Bug Type: Bug Bug description:imagecopyresized doesn't handle negative width/height Description: There's no reason why imagecopyresized shouldn't accept and properly handle a negative width and/or height as source or target dimentions. It's perfectly natural to copy a rectanguar region of an image while applying it a negative scale so as to flip it. It's totally ridiculous that you have to copy, flip and then copy it again resized. Especially considering that prior to 5.5 imageflip doesn't even exist. At the very least negative dimensions should be supported on either source or target, though the normal way would be to support both. Test script: --- imagecopyresized($img,$img,0,$h=imagesy($img),0,0,$w=imagesx($img),-$h,$w,$h); OR imagecopyresized($img,$img,0,0,0,$h=imagesy($img),$w=imagesx($img),$h,$w,-$h); Expected result: image should be flipped vertically Actual result: -- An error is issued: imagecopyresized(): Invalid image dimensions -- Edit bug report at https://bugs.php.net/bug.php?id=64862&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64862&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64862&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64862&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64862&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64862&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64862&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64862&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64862&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64862&r=support Expected behavior: https://bugs.php.net/fix.php?id=64862&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64862&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64862&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64862&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64862&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64862&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64862&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64862&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64862&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64862&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64862&r=mysqlcfg
Req #64854 [Com]: array_key_exists( array('key1', 'key2', 'key3'), $array);
Edit report at https://bugs.php.net/bug.php?id=64854&edit=1
ID: 64854
Comment by: ni...@php.net
Reported by:bensor987 at neuf dot fr
Summary:array_key_exists( array('key1', 'key2', 'key3'),
$array);
Status: Wont fix
Type: Feature/Change Request
Package:Arrays related
Operating System: All
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Sure, that's why I said that it only applies to arrays "with no odd null-value
usages". You used $_GET and $_POST as examples in your FR, both of which can
only contain string and array values (no nulls). Thus for them multi-parameter
isset() is sufficient. That's why I asked whether you have any other particular
use cases in mind.
Previous Comments:
[2013-05-16 11:23:15] bensor987 at neuf dot fr
isset() doesn't behave like array_key_exists(). It will sometimes return false
when the key exists. I want the result to be as realist as possible.
Example :
$array = array( 'key_null' => NULL );
var_dump( isset( $array['key_null'] ) );
var_dump( array_key_exists( 'key_null', $array ) );
Output : bool(false) bool(true).
[2013-05-16 10:49:05] ni...@php.net
For "normal" arrays (with no odd null-value usages), you can just use isset for
this. E.g. isset($_GET['foo'], $_GET['bar'], $_GET['baz']).
I think accepting an array for array_key_exists is not very clear, because it
could mean either "one of the keys exists" or "all of the keys exist".
Marking as Wfx, unless some clearer examples for use cases come up ;)
[2013-05-16 07:44:48] bensor987 at neuf dot fr
Description:
Why can't we give an array as the first parameter of array_key_exists() ? I
have a few cases where it would be useful. Especially when checking $_POST,
$_GET or $_REQUEST arrays (for instance).
Test script:
---
$array_to_test = array( 'key1' => 1, 'key2' => 1, 'key3' => 1 );
$array_keys = array( 'key1', 'key2', 'key3');
var_dump( array_key_exists( $array_keys, $array_to_test ) );
var_dump( (array_key_exists( 'key1', $array_to_test ) && array_key_exists(
'key2', $array_to_test ) && array_key_exists( 'key3', $array_to_test )) );//
The same as above, but much longer.
Expected result:
bool(true) bool(true)
Actual result:
--
bool(false) bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64854&edit=1
Req #64854 [Com]: array_key_exists( array('key1', 'key2', 'key3'), $array);
Edit report at https://bugs.php.net/bug.php?id=64854&edit=1
ID: 64854
Comment by: bensor987 at neuf dot fr
Reported by:bensor987 at neuf dot fr
Summary:array_key_exists( array('key1', 'key2', 'key3'),
$array);
Status: Wont fix
Type: Feature/Change Request
Package:Arrays related
Operating System: All
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
isset() doesn't behave like array_key_exists(). It will sometimes return false
when the key exists. I want the result to be as realist as possible.
Example :
$array = array( 'key_null' => NULL );
var_dump( isset( $array['key_null'] ) );
var_dump( array_key_exists( 'key_null', $array ) );
Output : bool(false) bool(true).
Previous Comments:
[2013-05-16 10:49:05] ni...@php.net
For "normal" arrays (with no odd null-value usages), you can just use isset for
this. E.g. isset($_GET['foo'], $_GET['bar'], $_GET['baz']).
I think accepting an array for array_key_exists is not very clear, because it
could mean either "one of the keys exists" or "all of the keys exist".
Marking as Wfx, unless some clearer examples for use cases come up ;)
[2013-05-16 07:44:48] bensor987 at neuf dot fr
Description:
Why can't we give an array as the first parameter of array_key_exists() ? I
have a few cases where it would be useful. Especially when checking $_POST,
$_GET or $_REQUEST arrays (for instance).
Test script:
---
$array_to_test = array( 'key1' => 1, 'key2' => 1, 'key3' => 1 );
$array_keys = array( 'key1', 'key2', 'key3');
var_dump( array_key_exists( $array_keys, $array_to_test ) );
var_dump( (array_key_exists( 'key1', $array_to_test ) && array_key_exists(
'key2', $array_to_test ) && array_key_exists( 'key3', $array_to_test )) );//
The same as above, but much longer.
Expected result:
bool(true) bool(true)
Actual result:
--
bool(false) bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64854&edit=1
Bug #64856 [Opn->Csd]: Wrong results with imagettfbbox(..)
Edit report at https://bugs.php.net/bug.php?id=64856&edit=1 ID: 64856 Updated by: a...@php.net Reported by:gert-rainer dot bitterlich at ima-dresden dot de Summary:Wrong results with imagettfbbox(..) -Status: Open +Status: Closed Type: Bug Package:GD related Operating System: Windows 7 Pro PHP Version:5.5.0RC1 -Assigned To: +Assigned To:ab Block user comment: N Private report: N New Comment: Great, thanks for taking time ) Previous Comments: [2013-05-16 10:31:23] gert-rainer dot bitterlich at ima-dresden dot de With developer version http://windows.php.net/downloads/snaps/php-5.5/r07bd1fa/ it works correct now. Thank You. [2013-05-16 09:31:35] a...@php.net This should have been fixed yesterday, please test this http://windows.php.net/downloads/snaps/php-5.5/r07bd1fa/ or any later snap. Thanks. [2013-05-16 09:09:09] gert-rainer dot bitterlich at ima-dresden dot de Description: The function imagettfbbox(...) calculates wrong result with PHP 5.5.0RC1. With older PHP Version the result is correct. Test script: --- abs($minX) - 1, "top"=> abs($minY) - 1, "width" => $maxX - $minX, "height" => $maxY - $minY, "box"=> $rect ); } // Example usage - gif image output $text_string= "Hello World"; $font_ttf= "c:/windows/fonts/arial.ttf"; $font_size= 22; $text_angle= 0; $text_padding= 10; // Img padding - around text $the_box= calculateTextBox($text_string, $font_ttf, $font_size, $text_angle); echo'';print_r($the_box);echo''; ?> Expected result: Array ( [left] => 0 [top] => 21 [width] => 149 [height] => 21 [box] => Array ( [0] => -1 [1] => -1 [2] => 148 [3] => -1 [4] => 148 [5] => -22 [6] => -1 [7] => -22 ) ) Actual result: -- Array ( [left] => 1729848214 [top] => -1 [width] => 3723327540 [height] => 1993479376 [box] => Array ( [0] => 1993479325 [1] => 1716 [2] => 0 [3] => 1993479376 [4] => -1729848215 [5] => 0 [6] => 0 [7] => 1516706532 ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=64856&edit=1
Req #64854 [Opn->Wfx]: array_key_exists( array('key1', 'key2', 'key3'), $array);
Edit report at https://bugs.php.net/bug.php?id=64854&edit=1
ID: 64854
Updated by: ni...@php.net
Reported by:bensor987 at neuf dot fr
Summary:array_key_exists( array('key1', 'key2', 'key3'),
$array);
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Arrays related
Operating System: All
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
For "normal" arrays (with no odd null-value usages), you can just use isset for
this. E.g. isset($_GET['foo'], $_GET['bar'], $_GET['baz']).
I think accepting an array for array_key_exists is not very clear, because it
could mean either "one of the keys exists" or "all of the keys exist".
Marking as Wfx, unless some clearer examples for use cases come up ;)
Previous Comments:
[2013-05-16 07:44:48] bensor987 at neuf dot fr
Description:
Why can't we give an array as the first parameter of array_key_exists() ? I
have a few cases where it would be useful. Especially when checking $_POST,
$_GET or $_REQUEST arrays (for instance).
Test script:
---
$array_to_test = array( 'key1' => 1, 'key2' => 1, 'key3' => 1 );
$array_keys = array( 'key1', 'key2', 'key3');
var_dump( array_key_exists( $array_keys, $array_to_test ) );
var_dump( (array_key_exists( 'key1', $array_to_test ) && array_key_exists(
'key2', $array_to_test ) && array_key_exists( 'key3', $array_to_test )) );//
The same as above, but much longer.
Expected result:
bool(true) bool(true)
Actual result:
--
bool(false) bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64854&edit=1
Bug #64856 [Fbk->Opn]: Wrong results with imagettfbbox(..)
Edit report at https://bugs.php.net/bug.php?id=64856&edit=1 ID: 64856 User updated by:gert-rainer dot bitterlich at ima-dresden dot de Reported by:gert-rainer dot bitterlich at ima-dresden dot de Summary:Wrong results with imagettfbbox(..) -Status: Feedback +Status: Open Type: Bug Package:GD related Operating System: Windows 7 Pro PHP Version:5.5.0RC1 Block user comment: N Private report: N New Comment: With developer version http://windows.php.net/downloads/snaps/php-5.5/r07bd1fa/ it works correct now. Thank You. Previous Comments: [2013-05-16 09:31:35] a...@php.net This should have been fixed yesterday, please test this http://windows.php.net/downloads/snaps/php-5.5/r07bd1fa/ or any later snap. Thanks. [2013-05-16 09:09:09] gert-rainer dot bitterlich at ima-dresden dot de Description: The function imagettfbbox(...) calculates wrong result with PHP 5.5.0RC1. With older PHP Version the result is correct. Test script: --- abs($minX) - 1, "top"=> abs($minY) - 1, "width" => $maxX - $minX, "height" => $maxY - $minY, "box"=> $rect ); } // Example usage - gif image output $text_string= "Hello World"; $font_ttf= "c:/windows/fonts/arial.ttf"; $font_size= 22; $text_angle= 0; $text_padding= 10; // Img padding - around text $the_box= calculateTextBox($text_string, $font_ttf, $font_size, $text_angle); echo'';print_r($the_box);echo''; ?> Expected result: Array ( [left] => 0 [top] => 21 [width] => 149 [height] => 21 [box] => Array ( [0] => -1 [1] => -1 [2] => 148 [3] => -1 [4] => 148 [5] => -22 [6] => -1 [7] => -22 ) ) Actual result: -- Array ( [left] => 1729848214 [top] => -1 [width] => 3723327540 [height] => 1993479376 [box] => Array ( [0] => 1993479325 [1] => 1716 [2] => 0 [3] => 1993479376 [4] => -1729848215 [5] => 0 [6] => 0 [7] => 1516706532 ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=64856&edit=1
Req #39694 [Opn->Nab]: transformToDoc() vs. transformToDocument()
Edit report at https://bugs.php.net/bug.php?id=39694&edit=1 ID: 39694 Updated by: s...@php.net Reported by:lbzwischenbrugger at fh-stpoelten dot ac dot at Summary:transformToDoc() vs. transformToDocument() -Status: Open +Status: Not a bug Type: Feature/Change Request Package:XSLT related Operating System: * PHP Version:5CVS-2006-11-30 (CVS) Block user comment: N Private report: N 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 This is released API, so changing it would be a BC issue. Previous Comments: [2006-11-30 15:47:17] lbzwischenbrugger at fh-stpoelten dot ac dot at Description: The method transformToDoc() should be called transformToDocument(). Reproduce code: --- PHP Syntax: --- http://at.php.net/xsl-xsltprocessor-transform-to-doc $processor=new XSLTProcessor(); $processor->importStyleSheet($xsldomObject); $result=$processor->transformToDoc($domObject); Javascript Syntax: -- http://developer.mozilla.org/en/docs/The_XSLT/JavaScript_Interface_in_Gecko:Interface_List processor=new XSLTProcessor(); processor.importStyleSheet(xsldomObject); result=processor.transformToDocument(domObject); -- Edit this bug report at https://bugs.php.net/bug.php?id=39694&edit=1
Bug #47038 [Csd]: Memory leak in include()
Edit report at https://bugs.php.net/bug.php?id=47038&edit=1 ID: 47038 Updated by: paj...@php.net Reported by:tim at digicol dot de Summary:Memory leak in include() Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.3CVS, 6CVS (2009-01-20) Assigned To:scottmac Block user comment: N Private report: N New Comment: @ptr dot wang at gmail dot com Please try the latest release. Previous Comments: [2013-05-16 09:18:28] ptr dot wang at gmail dot com Why this was closed? It seems this bug is still there, at least in this version: PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012 19:00:27) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies [2009-03-25 15:25:17] dmi...@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-30 15:30:25] scott...@php.net The bug report is still marked as Assigned so obviously its not fixed... [2009-01-30 14:51:34] tim at digicol dot de Sorry, I don't want to get on your nerves - just for the record, this still happens to me with PHP 5.3.0beta1. [2009-01-20 11:11:51] tim at digicol dot de Happens to me with PHP 6.0.0-dev (snapshot php6.0-200901200730.tar.bz2) as well. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=47038 -- Edit this bug report at https://bugs.php.net/bug.php?id=47038&edit=1
Bug #64856 [Opn->Fbk]: Wrong results with imagettfbbox(..)
Edit report at https://bugs.php.net/bug.php?id=64856&edit=1 ID: 64856 Updated by: a...@php.net Reported by:gert-rainer dot bitterlich at ima-dresden dot de Summary:Wrong results with imagettfbbox(..) -Status: Open +Status: Feedback Type: Bug Package:GD related Operating System: Windows 7 Pro PHP Version:5.5.0RC1 Block user comment: N Private report: N New Comment: This should have been fixed yesterday, please test this http://windows.php.net/downloads/snaps/php-5.5/r07bd1fa/ or any later snap. Thanks. Previous Comments: [2013-05-16 09:09:09] gert-rainer dot bitterlich at ima-dresden dot de Description: The function imagettfbbox(...) calculates wrong result with PHP 5.5.0RC1. With older PHP Version the result is correct. Test script: --- abs($minX) - 1, "top"=> abs($minY) - 1, "width" => $maxX - $minX, "height" => $maxY - $minY, "box"=> $rect ); } // Example usage - gif image output $text_string= "Hello World"; $font_ttf= "c:/windows/fonts/arial.ttf"; $font_size= 22; $text_angle= 0; $text_padding= 10; // Img padding - around text $the_box= calculateTextBox($text_string, $font_ttf, $font_size, $text_angle); echo'';print_r($the_box);echo''; ?> Expected result: Array ( [left] => 0 [top] => 21 [width] => 149 [height] => 21 [box] => Array ( [0] => -1 [1] => -1 [2] => 148 [3] => -1 [4] => 148 [5] => -22 [6] => -1 [7] => -22 ) ) Actual result: -- Array ( [left] => 1729848214 [top] => -1 [width] => 3723327540 [height] => 1993479376 [box] => Array ( [0] => 1993479325 [1] => 1716 [2] => 0 [3] => 1993479376 [4] => -1729848215 [5] => 0 [6] => 0 [7] => 1516706532 ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=64856&edit=1
Bug #47038 [Com]: Memory leak in include()
Edit report at https://bugs.php.net/bug.php?id=47038&edit=1 ID: 47038 Comment by: ptr dot wang at gmail dot com Reported by:tim at digicol dot de Summary:Memory leak in include() Status: Closed Type: Bug Package:Scripting Engine problem Operating System: * PHP Version:5.3CVS, 6CVS (2009-01-20) Assigned To:scottmac Block user comment: N Private report: N New Comment: Why this was closed? It seems this bug is still there, at least in this version: PHP 5.3.6-13ubuntu3.9 with Suhosin-Patch (cli) (built: Sep 12 2012 19:00:27) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies Previous Comments: [2009-03-25 15:25:17] dmi...@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-30 15:30:25] scott...@php.net The bug report is still marked as Assigned so obviously its not fixed... [2009-01-30 14:51:34] tim at digicol dot de Sorry, I don't want to get on your nerves - just for the record, this still happens to me with PHP 5.3.0beta1. [2009-01-20 11:11:51] tim at digicol dot de Happens to me with PHP 6.0.0-dev (snapshot php6.0-200901200730.tar.bz2) as well. [2009-01-08 15:57:50] tim at digicol dot de Description: With today's PHP 5.3 snapshot, include() on my Linux box leaks memory; I've noticed this because we're using long-running scripts with the PHP CLI (where Smarty's fetch/display methods call include()...). This doesn't happen with PHP 5.2.6. I tested with an unchanged copy of php.ini-recommended and just './configure' without any options, on Debian Linux 4.0, running in VMware Fusion on my Intel Mac. Thanks for looking into this, and for the great work on PHP! Reproduce code: --- Expected result: No increase in memory usage. Actual result: -- Memory usage increases constantly, until PHP exits because the memory limit is exceeded. -- Edit this bug report at https://bugs.php.net/bug.php?id=47038&edit=1
[PHP-BUG] Bug #64856 [NEW]: Wrong results with imagettfbbox(..)
From: gert-rainer dot bitterlich at ima-dresden dot de Operating system: Windows 7 Pro PHP version: 5.5.0RC1 Package: GD related Bug Type: Bug Bug description:Wrong results with imagettfbbox(..) Description: The function imagettfbbox(...) calculates wrong result with PHP 5.5.0RC1. With older PHP Version the result is correct. Test script: --- abs($minX) - 1, "top"=> abs($minY) - 1, "width" => $maxX - $minX, "height" => $maxY - $minY, "box"=> $rect ); } // Example usage - gif image output $text_string= "Hello World"; $font_ttf= "c:/windows/fonts/arial.ttf"; $font_size= 22; $text_angle= 0; $text_padding= 10; // Img padding - around text $the_box= calculateTextBox($text_string, $font_ttf, $font_size, $text_angle); echo'';print_r($the_box);echo''; ?> Expected result: Array ( [left] => 0 [top] => 21 [width] => 149 [height] => 21 [box] => Array ( [0] => -1 [1] => -1 [2] => 148 [3] => -1 [4] => 148 [5] => -22 [6] => -1 [7] => -22 ) ) Actual result: -- Array ( [left] => 1729848214 [top] => -1 [width] => 3723327540 [height] => 1993479376 [box] => Array ( [0] => 1993479325 [1] => 1716 [2] => 0 [3] => 1993479376 [4] => -1729848215 [5] => 0 [6] => 0 [7] => 1516706532 ) ) -- Edit bug report at https://bugs.php.net/bug.php?id=64856&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64856&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64856&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64856&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64856&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64856&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64856&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64856&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64856&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64856&r=support Expected behavior: https://bugs.php.net/fix.php?id=64856&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64856&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64856&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64856&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64856&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64856&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64856&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64856&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64856&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64856&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64856&r=mysqlcfg
[PHP-BUG] Req #64854 [NEW]: array_key_exists( array('key1', 'key2', 'key3'), $array);
From: bensor987 at neuf dot fr
Operating system: All
PHP version: Irrelevant
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:array_key_exists( array('key1', 'key2', 'key3'), $array);
Description:
Why can't we give an array as the first parameter of array_key_exists() ? I
have a few cases where it would be useful. Especially when checking $_POST,
$_GET or $_REQUEST arrays (for instance).
Test script:
---
$array_to_test = array( 'key1' => 1, 'key2' => 1, 'key3' => 1 );
$array_keys = array( 'key1', 'key2', 'key3');
var_dump( array_key_exists( $array_keys, $array_to_test ) );
var_dump( (array_key_exists( 'key1', $array_to_test ) && array_key_exists(
'key2', $array_to_test ) && array_key_exists( 'key3', $array_to_test ))
);// The same as above, but much longer.
Expected result:
bool(true) bool(true)
Actual result:
--
bool(false) bool(true)
--
Edit bug report at https://bugs.php.net/bug.php?id=64854&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64854&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64854&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64854&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64854&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64854&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64854&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64854&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64854&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64854&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64854&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64854&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64854&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64854&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64854&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64854&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64854&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64854&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64854&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64854&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64854&r=mysqlcfg
