#33927 [NEW]: $_GET[] or $_POST[]: irrelevant
From: johny at mysteri dot lu Operating system: Linux Debian PHP version: 4.3.11 PHP Bug Type: Variables related Bug description: $_GET[] or $_POST[]: irrelevant Description: I saw it, while coding a form. I put into the form an input, type hidden, with name "func and value "editmember". Then, in the file where the posted data should be read, I made a mistake, I put $_GET['func'], but it still recognoized it, also when it was send by POST (yes I'm sute that the form has POST as method). Normally, it should only recognoize it when I write $_POST['func']. Here's the configure line of the PHP installed on the used server: Command '../configure' '--prefix=/usr' '--with-apxs2=/usr/bin/apxs2' '--with-config-file-path=/etc/php4/apache2' '--enable-memory-limit' '--disable-debug' '--with-regex=php' '--disable-rpath' '--disable-static' '--with-pic' '--with-layout=GNU' '--with-pear=/usr/share/php' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db4' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--with-xmlrpc' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-kerberos=/usr' '--with-openssl=/usr' '--with-zip=/usr' '--enable-dbx' '--with-mime-magic=/usr/share/misc/file/magic.mime' '--with-exec-dir=/usr/lib/php4/libexec' '--without-mm' '--without-mysql' '--without-sybase-ct' Reproduce code: --- "; }; ?> Expected result: Normally, pushing the Button "Submit", the Form should be displayed once more. Actual result: -- PHP Result -- Edit bug report at http://bugs.php.net/?id=33927&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33927&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33927&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33927&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33927&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33927&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33927&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33927&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33927&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33927&r=support Expected behavior: http://bugs.php.net/fix.php?id=33927&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33927&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33927&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33927&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33927&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33927&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33927&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33927&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33927&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33927&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33927&r=mysqlcfg
#33926 [NEW]: Maybe a nice function for future releases
From: webmaster at baz-x dot at
Operating system: WinXP Home Edition Build 2600
PHP version: 4.3.11
PHP Bug Type: Feature/Change Request
Bug description: Maybe a nice function for future releases
Description:
Sorry if I did something wrong. This is my first time I submit a report.
(Btw: when adding a note, the link "Click here to request a feature."
redirects to bugs.php.net, is this correct?)
I was looking for a function that deletes either integer keys or string
keys (needed for my caching).
As I didn't find a function I created a simple one.
$value )
{
if ( $extract_type == 1 && is_string($key) )
{
// delete string keys
unset($array[$key]);
}
elseif ( $extract_type == 2 && is_int($key) )
{
// delete integer keys
unset($array[$key]);
}
}
return $array;
}
?>
You can of course define constants to have a nicer look, I have chosen
these: EXTR_INT = 1; EXTR_STRING = 2
EXTR_INT will return an array where keys are only integer while
EXTR_STRING will return an array where keys are only string
I hope you find it useful.
--
Edit bug report at http://bugs.php.net/?id=33926&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33926&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33926&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33926&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33926&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33926&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33926&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33926&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33926&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33926&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33926&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33926&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33926&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33926&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33926&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33926&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33926&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33926&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33926&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33926&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33926&r=mysqlcfg
#22999 [Asn->Fbk]: proc_close() sometimes returns -1 when called process exited with status of 0
ID: 22999
Updated by: [EMAIL PROTECTED]
Reported By: phil at concretecomputing dot co dot uk
-Status: Assigned
+Status: Feedback
Bug Type: Filesystem function related
Operating System: sun os
PHP Version: 5CVS
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2003-10-08 07:23:47] [EMAIL PROTECTED]
Won't fix in PHP 4 (changes required are too messy to
introduce to stable branch), will fix in PHP 5.
[2003-04-17 13:37:25] michael at six dot de
We have the same issue with pclose()
Testcase:
Most of the time $status is -1, sometimes 0.
PHP-4.3.2RC1, Solaris 7, --enable-sigchild
PHP is compiled with --enable-sigchild because the oracle client is
needed too, this was recommended in former bug descriptions. Is this
still the case for oracle?
[2003-04-01 05:00:37] [EMAIL PROTECTED]
This is a known issue when compiling with
--enable-sigchild.
I will see if it can be fixed.
[2003-04-01 04:17:36] phil at concretecomputing dot co dot uk
I'm trying to run a command via proc_open(). The command always
succeeds (exits with status of 0), so I would expect that proc_close()
would always return 0. Most of the time it does, but sometimes it
returns -1.
Here is a script which reproduces the problem. On my system, if you run
the script many times, most times the status reported will be 0, but
occasionally it will be -1.
array("pipe", "r"),// stdin is a
pipe that the child will read from
1 => array("pipe", "w"),// stdout is a
pipe that the child will write to
2 => array("pipe", "w") // stderr is a
pipe that the child will write to
);
$process = proc_open("ps -ef", $inputArray, $outputArray);
if (is_resource($process)) {
fclose($outputArray[0]);
// Grab the output
$output="";
while(!feof($outputArray[1])) {
$output .= fgets($outputArray[1], 1024);
}
// Extract any error output
$errorOutput = "";
while(!feof($outputArray[2])) {
$errorOutput .= fgets($outputArray[2], 1024);
}
// It is important that you close any pipes before calling
proc_close() in order to avoid a deadlock
fclose($outputArray[1]);
fclose($outputArray[2]);
$status = proc_close($process);
echo "proc_close() return result: $status\n";
echo "ps error output: [$errorOutput]\n";
echo "ps output: [$output]\n";
}
echo "Done\n";
?>
PHP is compiled as follows:
'./configure' '--with-apxs=/usr/local/apache1.3.27-nerens3.4/bin/apxs'
'--without-mysql' '--enable-track-vars' '--enable-sigchild'
'--with-oci8=/opt/oracle/product/9.0.1' '--enable-apc' '--with-xml'
'--with-expat-dir=/usr/local/expat' '--with-zlib=/usr/local/zlib'
'--with-curl=/usr/local/curl' '--with-mhash=/usr/local/mhash'
'--with-mcrypt=/usr/local/libmcrypt'
I have tried to have a look at what is going on using truss and I think
it may be caused by another function within php doing a wait() and
getting the exit status for the child so that the wait() in proc_close
returns with ECHLD.
While testing using the above script, I have found that if I add a call
to sleep after the proc_open() call then proc_close() _always_ returns
-1 (and the sleep() call has no effect)
--
Edit this bug report at http://bugs.php.net/?id=22999&edit=1
#33920 [Opn->Bgs]: Wrong shows hour
ID: 33920
Updated by: [EMAIL PROTECTED]
Reported By: php-work at yandex dot ru
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-07-29 (dev)
New Comment:
You're supposed to set the timezone to whatever your timezone IS, not
to GMT. Do NOT reopen this, there is no bug here.
Previous Comments:
[2005-07-29 22:48:48] php-work at yandex dot ru
Sorry, on PHP5.0.4
[2005-07-29 22:45:59] php-work at yandex dot ru
And else. I tried it (echo date('H');) on PHP5.0.4b3 and result is
true, 00
[2005-07-29 22:43:22] php-work at yandex dot ru
I has tried date_default_timezone_set('GMT'), but no result.
date_default_timezone_get return UTC. If add the
date_default_timezone_set('GMT'), return GMT.
Script:
print GMT20 (but current time - 00:42).
[2005-07-29 20:00:43] [EMAIL PROTECTED]
Probably your TZ environment var is set to GMT.
So, you need to use the date_default_timezone_set() function to overide
it.
[2005-07-29 19:22:54] php-work at yandex dot ru
Tried, no effect.
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/33920
--
Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33542 [NoF->Csd]: If referencing a function that returns a variable, error occurs
ID: 33542
User updated by: rick dot martinez at gmail dot com
Reported By: rick dot martinez at gmail dot com
-Status: No Feedback
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: All
PHP Version: 5CVS-2005-07-01 (dev)
New Comment:
This bug was resolved by changing some code.
If you add a & before the name of the function in the function
declaration:
function &myFunction() { }
it allows it to be passed as a reference. Hope this helps.
Previous Comments:
[2005-07-29 23:35:59] luciano_closs at hotmail dot com
And about the last post: I'm using PHP 4.4.1.
[2005-07-29 22:06:11] luciano_closs at hotmail dot com
I have the same error. I suppose that I don't need to get a xml parser
by reference, I do not analyse all the code yet, since this code was
get from an Open Source Project.
I posted a sample code at:
http://www.infopoa-ti.com/xml_parser_by_ref.zip
[2005-07-10 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-07-02 12:12:13] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-07-01 23:47:05] rick dot martinez at gmail dot com
Description:
I have a static function that is supposed to return an instance of an
object.
$object = &Object2::getObject();
This works perfectly in PHP 5.0.4.4 but breaks in PHP5.0.x CVS. It
returns error:
* Only variables should be assigned by reference
If I create an instance for that variable first, it gets fixed.
$object = new object;
$object = &Object2::getObject();
Is this proper behavior or is this some sort of bug? If it is proper
behavior, please change this back. It breaks a LOT of my code. Thanks.
--
Edit this bug report at http://bugs.php.net/?id=33542&edit=1
#33542 [Com]: If referencing a function that returns a variable, error occurs
ID: 33542 Comment by: luciano_closs at hotmail dot com Reported By: rick dot martinez at gmail dot com Status: No Feedback Bug Type: Scripting Engine problem Operating System: All PHP Version: 5CVS-2005-07-01 (dev) New Comment: And about the last post: I'm using PHP 4.4.1. Previous Comments: [2005-07-29 22:06:11] luciano_closs at hotmail dot com I have the same error. I suppose that I don't need to get a xml parser by reference, I do not analyse all the code yet, since this code was get from an Open Source Project. I posted a sample code at: http://www.infopoa-ti.com/xml_parser_by_ref.zip [2005-07-10 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-07-02 12:12:13] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-07-01 23:47:05] rick dot martinez at gmail dot com Description: I have a static function that is supposed to return an instance of an object. $object = &Object2::getObject(); This works perfectly in PHP 5.0.4.4 but breaks in PHP5.0.x CVS. It returns error: * Only variables should be assigned by reference If I create an instance for that variable first, it gets fixed. $object = new object; $object = &Object2::getObject(); Is this proper behavior or is this some sort of bug? If it is proper behavior, please change this back. It breaks a LOT of my code. Thanks. -- Edit this bug report at http://bugs.php.net/?id=33542&edit=1
#33914 [Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914
User updated by: me at thomaskeller dot biz
Reported By: me at thomaskeller dot biz
Status: Bogus
Bug Type: GD related
Operating System: Linux 2.4 shared hosting
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
> Again it's not a bug.
> You have to set the transparent color correctly
> in the destination image.
So what means "correctly" here? I've tried several
dozens of combination to get the desired result
but failed with each. I copied palettes over, tried to
copy into a 32bit target image while later shrinking
it back via imagetruecolortopalette, and more.
I'll promise I'll shut up if you just give me a few
lines of CORRECT code. The docs don't help me on my
problem.
I've also noticed that a list($r, $g, $b) =
imagecolorsforindex(...) doesn't work as suspected,
because all three variables are unset. This is my
current code:
imagecolortransparent on $im_target afterwards returns
the index for the transparent color (white), but still the
background of the image has another color (rgb 128,64,88).
If I set this color to be transparent, nothing happens
(its still there).
Previous Comments:
[2005-07-29 18:19:57] [EMAIL PROTECTED]
Again it's not a bug.
You have to set the transparent color correctly in the destination
image.
--Pierre
[2005-07-29 18:12:15] [EMAIL PROTECTED]
RTFM: http://www.php.net/imagecolortransparent
[2005-07-29 17:36:48] me at thomaskeller dot biz
I have already provided a sample script, which is available on
http://thomaskeller.biz/work/php/PHP_GIF/image.php, the source for this
file is http://thomaskeller.biz/work/php/PHP_GIF/image.phps [0].
The test image which fails to be scaled is
http://thomaskeller.biz/work/php/PHP_GIF/rose.gif
As you can see here [0] the problematic code seems to be (shortened):
-1) // transparent color found?
{
list($r, $g, $b) = imagecolorsforindex($im_src,$idx);
$transColor = imagecolorexact($im_target, $r, $g, $b);
imagecolortransparent($im_target, $transColor);
}
?>
where I try to receive the index of the transparent color
of the original image, then find the rgb value of this color and
finally create a new color on the target image using the rgb value and
set it as transparent color.
[2005-07-29 17:19:21] [EMAIL PROTECTED]
Provide a sample (and little) script and the images causing your
problem may help.
For what you said, the "random" color may in fact be the background.
You have to set the transparent color yourself to the dest image.
Short version, it's not a bug as far as I can tell now.
I keep this bug to bogus, if you have a reproducable script with one
image, turn it back to open.
[2005-07-29 02:37:12] me at thomaskeller dot biz
Description:
Following use case:
Uploaded images should be shrinked to a certain size according to our
guidelines.
Works with jpeg/ png (not palette based) images without a problem,
problems arise when used palette based (8bit) images. Resizing via
imagecopyresampled/ imagecopyresize works only for images WITHOUT a
transparency color set properly. If a transparency color is set in the
image, the value of this color is just ignored and a random background
color is applied to the "transparent" area. It makes no difference if
the image is outputted as gif or 8bit png.
If imagecopyresampled/imagecopyresized is called with the same
width/height for the source and the target image, the transparency
keeps intact.
Reproduce code:
---
I've setuped a few things on a test server:
PHPInfo:
http://thomaskeller.biz/work/php/PHP_GIF/info.php
Testfile:
http://thomaskeller.biz/work/php/PHP_GIF/image.php
Testfile (Source):
http://thomaskeller.biz/work/php/PHP_GIF/image.phps
image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by
default, but you can load an own gif file via URL like
image.php?filename=http://your.server.com/file.gif
The loaded image is per default resized to its double width/ height.
--
Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33920 [Opn]: Wrong shows hour
ID: 33920
User updated by: php-work at yandex dot ru
Reported By: php-work at yandex dot ru
Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-07-29 (dev)
New Comment:
Sorry, on PHP5.0.4
Previous Comments:
[2005-07-29 22:45:59] php-work at yandex dot ru
And else. I tried it (echo date('H');) on PHP5.0.4b3 and result is
true, 00
[2005-07-29 22:43:22] php-work at yandex dot ru
I has tried date_default_timezone_set('GMT'), but no result.
date_default_timezone_get return UTC. If add the
date_default_timezone_set('GMT'), return GMT.
Script:
print GMT20 (but current time - 00:42).
[2005-07-29 20:00:43] [EMAIL PROTECTED]
Probably your TZ environment var is set to GMT.
So, you need to use the date_default_timezone_set() function to overide
it.
[2005-07-29 19:22:54] php-work at yandex dot ru
Tried, no effect.
[2005-07-29 18:14:20] [EMAIL PROTECTED]
Set the timezone in php.ini using date.timezone setting.
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/33920
--
Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33920 [Opn]: Wrong shows hour
ID: 33920
User updated by: php-work at yandex dot ru
Reported By: php-work at yandex dot ru
Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-07-29 (dev)
New Comment:
And else. I tried it (echo date('H');) on PHP5.0.4b3 and result is
true, 00
Previous Comments:
[2005-07-29 22:43:22] php-work at yandex dot ru
I has tried date_default_timezone_set('GMT'), but no result.
date_default_timezone_get return UTC. If add the
date_default_timezone_set('GMT'), return GMT.
Script:
print GMT20 (but current time - 00:42).
[2005-07-29 20:00:43] [EMAIL PROTECTED]
Probably your TZ environment var is set to GMT.
So, you need to use the date_default_timezone_set() function to overide
it.
[2005-07-29 19:22:54] php-work at yandex dot ru
Tried, no effect.
[2005-07-29 18:14:20] [EMAIL PROTECTED]
Set the timezone in php.ini using date.timezone setting.
[2005-07-29 16:37:50] php-work at yandex dot ru
Description:
Code:
print Fri, 29 Jul 2005 14:22:56 +, but stated time zone:
(GMT+03:00) Moscow.
I tried to use other time zone, setlocale, but result is not changed.
--
Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33920 [Bgs->Opn]: Wrong shows hour
ID: 33920
User updated by: php-work at yandex dot ru
Reported By: php-work at yandex dot ru
-Status: Bogus
+Status: Open
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-07-29 (dev)
New Comment:
I has tried date_default_timezone_set('GMT'), but no result.
date_default_timezone_get return UTC. If add the
date_default_timezone_set('GMT'), return GMT.
Script:
print GMT20 (but current time - 00:42).
Previous Comments:
[2005-07-29 20:00:43] [EMAIL PROTECTED]
Probably your TZ environment var is set to GMT.
So, you need to use the date_default_timezone_set() function to overide
it.
[2005-07-29 19:22:54] php-work at yandex dot ru
Tried, no effect.
[2005-07-29 18:14:20] [EMAIL PROTECTED]
Set the timezone in php.ini using date.timezone setting.
[2005-07-29 16:37:50] php-work at yandex dot ru
Description:
Code:
print Fri, 29 Jul 2005 14:22:56 +, but stated time zone:
(GMT+03:00) Moscow.
I tried to use other time zone, setlocale, but result is not changed.
--
Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33542 [Com]: If referencing a function that returns a variable, error occurs
ID: 33542 Comment by: luciano_closs at hotmail dot com Reported By: rick dot martinez at gmail dot com Status: No Feedback Bug Type: Scripting Engine problem Operating System: All PHP Version: 5CVS-2005-07-01 (dev) New Comment: I have the same error. I suppose that I don't need to get a xml parser by reference, I do not analyse all the code yet, since this code was get from an Open Source Project. I posted a sample code at: http://www.infopoa-ti.com/xml_parser_by_ref.zip Previous Comments: [2005-07-10 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-07-02 12:12:13] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-07-01 23:47:05] rick dot martinez at gmail dot com Description: I have a static function that is supposed to return an instance of an object. $object = &Object2::getObject(); This works perfectly in PHP 5.0.4.4 but breaks in PHP5.0.x CVS. It returns error: * Only variables should be assigned by reference If I create an instance for that variable first, it gets fixed. $object = new object; $object = &Object2::getObject(); Is this proper behavior or is this some sort of bug? If it is proper behavior, please change this back. It breaks a LOT of my code. Thanks. -- Edit this bug report at http://bugs.php.net/?id=33542&edit=1
#33925 [Opn->Csd]: __construct() cause __destruct() call
ID: 33925 User updated by: deadman_great at mail dot ru Reported By: deadman_great at mail dot ru -Status: Open +Status: Closed Bug Type: Class/Object related Operating System: RH Redora, core 2 PHP Version: 5.0.4 New Comment: Sorry. Bug magically disappear. Previous Comments: [2005-07-29 21:56:17] deadman_great at mail dot ru Description: Destructor called after constructor. My configure string: ./configure --prefix=/usr/local --with-apache2=../httpd-2.0.53 --with-apxs2=/usr/local/apache2/bin/apxs --with-mod_charset --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --with-gd --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/local --with-zlib --enable-memory-limit --enable-exif --with-ttf --enable-gd-native-ttf --with-openssl=/usr/local --with-iconv --with-curl=/usr/local --enable-ftp --enable-sockets --enable-maintainer-zts Reproduce code: --- Expected result: [BEFORE][CONSTRUCTOR][AFTER][DESTRUCTOR] Actual result: -- [BEFORE][CONSTRUCTOR][DESTRUCTOR][AFTER][DESTRUCTOR] -- Edit this bug report at http://bugs.php.net/?id=33925&edit=1
#33925 [NEW]: __construct() cause __destruct() call
From: deadman_great at mail dot ru Operating system: RH Redora, core 2 PHP version: 5.0.4 PHP Bug Type: Class/Object related Bug description: __construct() cause __destruct() call Description: Destructor called after constructor. My configure string: ./configure --prefix=/usr/local --with-apache2=../httpd-2.0.53 --with-apxs2=/usr/local/apache2/bin/apxs --with-mod_charset --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --with-gd --with-jpeg-dir=/usr/local --with-png-dir=/usr/local --with-freetype-dir=/usr/local --with-zlib --enable-memory-limit --enable-exif --with-ttf --enable-gd-native-ttf --with-openssl=/usr/local --with-iconv --with-curl=/usr/local --enable-ftp --enable-sockets --enable-maintainer-zts Reproduce code: --- Expected result: [BEFORE][CONSTRUCTOR][AFTER][DESTRUCTOR] Actual result: -- [BEFORE][CONSTRUCTOR][DESTRUCTOR][AFTER][DESTRUCTOR] -- Edit bug report at http://bugs.php.net/?id=33925&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33925&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33925&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33925&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33925&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33925&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33925&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33925&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33925&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33925&r=support Expected behavior: http://bugs.php.net/fix.php?id=33925&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33925&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33925&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33925&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33925&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33925&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33925&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33925&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33925&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33925&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33925&r=mysqlcfg
#33884 [Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
Updated by: [EMAIL PROTECTED]
Reported By: php-bug-33884 at ryandesign dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
Hint: Try SEARCH to find the duplicate report..
Previous Comments:
[2005-07-29 21:46:22] [EMAIL PROTECTED]
Thank you for wasting my time (again).
[2005-07-29 19:09:08] php-bug-33884 at ryandesign dot com
I realize you must be very busy and that form responses let
you handle bugs quicker, but I can't help but feel a little
put off by them. I spent time analyzing a situation and
writing it up in detail, only to have it shut down with no
discussion by form responses. In particular, beginning your
response with "Please do not submit the same bug more than
once" makes it sound like I did so on purpose. (Your first
response, which began "Thank you [...], but [...]" was
better in this regard.) And especially in the case of
duplicate bugs, it's essential that you let me know the
other bug number, so that I can check and see whether it is
truly the same bug. With the speed with which you must work
through new bugs, I imagine some would get incorrectly
classified; surely it's in your best interest to have us
double-check for you.
I'm also not sure what I think about your deleting comments
from this bug. You closed my bug as bogus, pasting in a form
response that it is not a bug. I wrote a detailed reply
further clarifying why I believe it is. You promptly deleted
your original response and my reply, to replace it with
another form response saying my bug is a duplicate, without
saying what of. Might not my clarification have been helpful
to the person who tries to solve the bug, whether or not it
is a duplicate? Since I was not able to find the bug of
which this one is a duplicate, might others not have the
same difficulty, and might they not possibly benefit from
having more-detailed information in this bug on which they
could search?
[2005-07-29 19:08:44] php-bug-33884 at ryandesign dot com
I'm sorry, I was not aware that I had submitted a duplicate. I
did search beforehand and was not able to find a similar bug.
Since you seem to have found one, could you please tell me its
bug number so I can have a look?
[2005-07-29 18:12:56] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
#33884 [Opn->Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
Updated by: [EMAIL PROTECTED]
Reported By: php-bug-33884 at ryandesign dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
Thank you for wasting my time (again).
Previous Comments:
[2005-07-29 19:09:08] php-bug-33884 at ryandesign dot com
I realize you must be very busy and that form responses let
you handle bugs quicker, but I can't help but feel a little
put off by them. I spent time analyzing a situation and
writing it up in detail, only to have it shut down with no
discussion by form responses. In particular, beginning your
response with "Please do not submit the same bug more than
once" makes it sound like I did so on purpose. (Your first
response, which began "Thank you [...], but [...]" was
better in this regard.) And especially in the case of
duplicate bugs, it's essential that you let me know the
other bug number, so that I can check and see whether it is
truly the same bug. With the speed with which you must work
through new bugs, I imagine some would get incorrectly
classified; surely it's in your best interest to have us
double-check for you.
I'm also not sure what I think about your deleting comments
from this bug. You closed my bug as bogus, pasting in a form
response that it is not a bug. I wrote a detailed reply
further clarifying why I believe it is. You promptly deleted
your original response and my reply, to replace it with
another form response saying my bug is a duplicate, without
saying what of. Might not my clarification have been helpful
to the person who tries to solve the bug, whether or not it
is a duplicate? Since I was not able to find the bug of
which this one is a duplicate, might others not have the
same difficulty, and might they not possibly benefit from
having more-detailed information in this bug on which they
could search?
[2005-07-29 19:08:44] php-bug-33884 at ryandesign dot com
I'm sorry, I was not aware that I had submitted a duplicate. I
did search beforehand and was not able to find a similar bug.
Since you seem to have found one, could you please tell me its
bug number so I can have a look?
[2005-07-29 18:12:56] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33924 [Opn->Bgs]: PHP leaks when occurs a parse error
ID: 33924 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: 5CVS-2005-07-29 (dev) New Comment: Expected behaviour. Previous Comments: [2005-07-29 21:42:52] [EMAIL PROTECTED] Description: PHP leaks when occurs a parse error. For example: php -r 'echo "a' it also happens with the interactive CLI mode. I have not tested in apache though. I'm using the GOTO dispatcher and I have the zend memory manager disabled. -- Edit this bug report at http://bugs.php.net/?id=33924&edit=1
#33837 [Opn->Csd]: ESQL Version numbering schema changed
ID: 33837
Updated by: [EMAIL PROTECTED]
Reported By: roland dot wintgen at t-online dot de
-Status: Open
+Status: Closed
Bug Type: Informix related
Operating System: Linux
PHP Version: 5CVS, 4CVS (2005-07-24)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-07-24 17:57:33] roland dot wintgen at t-online dot de
IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.UC1
Software Serial Number AAA#B00
[2005-07-24 16:28:54] [EMAIL PROTECTED]
What exactly is the output of this:
# $INFORMIXDIR/bin/esql -V
[2005-07-24 14:13:41] roland dot wintgen at t-online dot de
with the latest snapshot php5-20050724103 the problem still exists.
phpinfo() shows an installed ESQL/C Version 2.90 whereas it should be
10.00.
Maybe it would help, not to test against the installed esql version but
the dbaccess version number. The change in config.m4 would be:
IFX_VERSION=[`$INFORMIXDIR/bin/dbaccess -V | grep "DB-Access Version" |
sed -ne '1 s/\(.*\)DB-Access Version \([0-9]*\)\.\([0-9]*\).*/\2\3/p'`]
this would give the correct version.
The Perl DBD::Informix developers still test against the esql version
but treat version numbers between 2.90 and 2.99 as the never released
version 9.60.
[2005-07-24 01:04:35] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-23 15:49:13] roland dot wintgen at t-online dot de
Description:
After installing the current CSDK 2.90, some database functions using
blobs will produce core dumps. This is due to IBM changed the version
number for the installed CSDK. Whereas esql -V for 2.80 shows "IBM
Informix CSDK 2.80, IBM Informix-ESQL Version 9.52.UC1", 2.90 will show
"IBM Informix CSDK Version 2.90, IBM Informix-ESQL Version 2.90.UC1".
This leads to a problem in ext/informix/config.m4 where the installed
version is read into IFX_VERSION. This value is interpreted in
ext/informix/ifx.ec around line 3258 to workaround a bug in older
versions. Now, with the wrong version number this will not run properly
and tries to deallocate the blob space twice. The bug shows also for PHP
4.3.X and 5.X.X.
Reproduce code:
---
ifx_textasvarchar(0);
ifx_blobinfile_mode(0);
// storing BLOB into database
$conn_id = @ifx_connect("database", "user", "password") or die("error
connecting to database!");
$blob_id = @ifx_create_blob(1, 0, "This text will be stored as blob")
or die("error creating blob!");
$blob[] = $blob_id;
$query_id = @ifx_query("insert into blobtable (blob) values (?)",
$conn_id, $blob) or die("error executing sql statement!");
ifx_free_result($query_id);
// retrieving BLOB
$query_id = @ifx_query("select blob from blobtable", $conn_id) or
die("error executing sql statement!");
$row_id = @ifx_fetch_row($query_id) or die("error fetching row!");
$blob_id = @ifx_get_blob($row_id["blob"]) or die("error retrieving
blob!");
ifx_free_result($query_id);
ifx_close($conn_id);
Expected result:
The small piece of code will try to store a small text as blob in a
database table and retrieve it.
Actual result:
--
[Sat Jul 23 15:45:04 2005] Script: 'ifx_blob_bug.php'
---
/usr/local/src/php-4.4.0/ext/informix/ifx.ec(3259) : Block 0x0977213C
status:
Beginning: Overrun (magic=0x0011, expected=0x7312F8DC)
End: Unknown
--
Edit this bug report at http://bugs.php.net/?id=33837&edit=1
#33924 [NEW]: PHP leaks when occurs a parse error
From: [EMAIL PROTECTED] Operating system: * PHP version: 5CVS-2005-07-29 (dev) PHP Bug Type: Scripting Engine problem Bug description: PHP leaks when occurs a parse error Description: PHP leaks when occurs a parse error. For example: php -r 'echo "a' it also happens with the interactive CLI mode. I have not tested in apache though. I'm using the GOTO dispatcher and I have the zend memory manager disabled. -- Edit bug report at http://bugs.php.net/?id=33924&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33924&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33924&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33924&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33924&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33924&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33924&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33924&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33924&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33924&r=support Expected behavior: http://bugs.php.net/fix.php?id=33924&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33924&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33924&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33924&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33924&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33924&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33924&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33924&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33924&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33924&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33924&r=mysqlcfg
#33922 [Bgs]: bad autoconf/automake versio check in ./buildconf
ID: 33922 User updated by: openmacnews at speakeasy dot net Reported By: openmacnews at speakeasy dot net Status: Bogus Bug Type: *Configuration Issues Operating System: OSX 10.4.2 PHP Version: 5CVS-2005-07-29 (dev) New Comment: just so i'm clear abt build/pkg-ing ... do you INTEND to recommend installing a version of automake from 2001? http://ftp.gnu.org/gnu/automake/ automake-1.5.tar.gz 23-Aug-2001 10:50 515k as opposed to a recent (1.9.5), let alone current (1.9.6), releases? as for running ./buildconf, from your own INSTALL: From here, build PHP as normal: $ cd /your/phpsrcdir --> $ ./buildconf $ ./configure --help Previous Comments: [2005-07-29 21:01:14] [EMAIL PROTECTED] There's nothing wrong with the warning. Also: you should not run buildconf for PHP yourself. Use the snapshots if you want to use bleeding edge. http://snaps.php.net/ [2005-07-29 20:56:27] openmacnews at speakeasy dot net Description: hi, i'm bldg php-cvs OSX 10.4.2. % ./buildconf reports: ... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. ... despite, on my sys: % automake --version automake (GNU automake) 1.9.5 % autoconf --version autoconf (GNU Autoconf) 2.59 richard -- Edit this bug report at http://bugs.php.net/?id=33922&edit=1
#33921 [Opn->Bgs]: Problem with tertiary statement in array
ID: 33921
Updated by: [EMAIL PROTECTED]
Reported By: rolf at winmutt dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5CVS-2005-07-29 (dev)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2005-07-29 19:05:36] rolf at winmutt dot com
Description:
The following line was not being interpreted properly in
php5-STABLE-200505181234:
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
$_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']
: $_REQUEST['accounts']['id']),'Add Service');
The array href element value was being passed as NULL, I corrected by
adding () around the tertiary statement :
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
($_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']:$_REQUEST['accounts']['id'])),'Add
Service');
Reproduce code:
---
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
$_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']
: $_REQUEST['accounts']['id']),'Add Service');
Expected result:
array('href'=>'?action=addService&billed_services[account_id]='.either
or val)
Actual result:
--
array('href'=>NULL)
--
Edit this bug report at http://bugs.php.net/?id=33921&edit=1
#33922 [Opn->Bgs]: bad autoconf/automake versio check in ./buildconf
ID: 33922 Updated by: [EMAIL PROTECTED] Reported By: openmacnews at speakeasy dot net -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: OSX 10.4.2 PHP Version: 5CVS-2005-07-29 (dev) New Comment: There's nothing wrong with the warning. Also: you should not run buildconf for PHP yourself. Use the snapshots if you want to use bleeding edge. http://snaps.php.net/ Previous Comments: [2005-07-29 20:56:27] openmacnews at speakeasy dot net Description: hi, i'm bldg php-cvs OSX 10.4.2. % ./buildconf reports: ... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. ... despite, on my sys: % automake --version automake (GNU automake) 1.9.5 % autoconf --version autoconf (GNU Autoconf) 2.59 richard -- Edit this bug report at http://bugs.php.net/?id=33922&edit=1
#33922 [NEW]: bad autoconf/automake versio check in ./buildconf
From: openmacnews at speakeasy dot net Operating system: OSX 10.4.2 PHP version: 5CVS-2005-07-29 (dev) PHP Bug Type: *Configuration Issues Bug description: bad autoconf/automake versio check in ./buildconf Description: hi, i'm bldg php-cvs OSX 10.4.2. % ./buildconf reports: ... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. ... despite, on my sys: % automake --version automake (GNU automake) 1.9.5 % autoconf --version autoconf (GNU Autoconf) 2.59 richard -- Edit bug report at http://bugs.php.net/?id=33922&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33922&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33922&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33922&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33922&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33922&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33922&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33922&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33922&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33922&r=support Expected behavior: http://bugs.php.net/fix.php?id=33922&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33922&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33922&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33922&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33922&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33922&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33922&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33922&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33922&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33922&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33922&r=mysqlcfg
#33920 [Opn->Bgs]: Wrong shows hour
ID: 33920 Updated by: [EMAIL PROTECTED] Reported By: php-work at yandex dot ru -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP SP2 PHP Version: 5CVS-2005-07-29 (dev) New Comment: Probably your TZ environment var is set to GMT. So, you need to use the date_default_timezone_set() function to overide it. Previous Comments: [2005-07-29 19:22:54] php-work at yandex dot ru Tried, no effect. [2005-07-29 18:14:20] [EMAIL PROTECTED] Set the timezone in php.ini using date.timezone setting. [2005-07-29 16:37:50] php-work at yandex dot ru Description: Code: print Fri, 29 Jul 2005 14:22:56 +, but stated time zone: (GMT+03:00) Moscow. I tried to use other time zone, setlocale, but result is not changed. -- Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33920 [Bgs->Opn]: Wrong shows hour
ID: 33920 User updated by: php-work at yandex dot ru Reported By: php-work at yandex dot ru -Status: Bogus +Status: Open Bug Type: Date/time related Operating System: Windows XP SP2 PHP Version: 5CVS-2005-07-29 (dev) New Comment: Tried, no effect. Previous Comments: [2005-07-29 18:14:20] [EMAIL PROTECTED] Set the timezone in php.ini using date.timezone setting. [2005-07-29 16:37:50] php-work at yandex dot ru Description: Code: print Fri, 29 Jul 2005 14:22:56 +, but stated time zone: (GMT+03:00) Moscow. I tried to use other time zone, setlocale, but result is not changed. -- Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33884 [Bgs->Opn]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
User updated by: php-bug-33884 at ryandesign dot com
Reported By: php-bug-33884 at ryandesign dot com
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
I realize you must be very busy and that form responses let
you handle bugs quicker, but I can't help but feel a little
put off by them. I spent time analyzing a situation and
writing it up in detail, only to have it shut down with no
discussion by form responses. In particular, beginning your
response with "Please do not submit the same bug more than
once" makes it sound like I did so on purpose. (Your first
response, which began "Thank you [...], but [...]" was
better in this regard.) And especially in the case of
duplicate bugs, it's essential that you let me know the
other bug number, so that I can check and see whether it is
truly the same bug. With the speed with which you must work
through new bugs, I imagine some would get incorrectly
classified; surely it's in your best interest to have us
double-check for you.
I'm also not sure what I think about your deleting comments
from this bug. You closed my bug as bogus, pasting in a form
response that it is not a bug. I wrote a detailed reply
further clarifying why I believe it is. You promptly deleted
your original response and my reply, to replace it with
another form response saying my bug is a duplicate, without
saying what of. Might not my clarification have been helpful
to the person who tries to solve the bug, whether or not it
is a duplicate? Since I was not able to find the bug of
which this one is a duplicate, might others not have the
same difficulty, and might they not possibly benefit from
having more-detailed information in this bug on which they
could search?
Previous Comments:
[2005-07-29 19:08:44] php-bug-33884 at ryandesign dot com
I'm sorry, I was not aware that I had submitted a duplicate. I
did search beforehand and was not able to find a similar bug.
Since you seem to have found one, could you please tell me its
bug number so I can have a look?
[2005-07-29 18:12:56] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33884 [Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
User updated by: php-bug-33884 at ryandesign dot com
Reported By: php-bug-33884 at ryandesign dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
I'm sorry, I was not aware that I had submitted a duplicate. I
did search beforehand and was not able to find a similar bug.
Since you seem to have found one, could you please tell me its
bug number so I can have a look?
Previous Comments:
[2005-07-29 18:12:56] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33921 [NEW]: Problem with tertiary statement in array
From: rolf at winmutt dot com
Operating system: Linux
PHP version: 5CVS-2005-07-29 (dev)
PHP Bug Type: Scripting Engine problem
Bug description: Problem with tertiary statement in array
Description:
The following line was not being interpreted properly in
php5-STABLE-200505181234:
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
$_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']
: $_REQUEST['accounts']['id']),'Add Service');
The array href element value was being passed as NULL, I corrected by
adding () around the tertiary statement :
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
($_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']:$_REQUEST['accounts']['id'])),'Add
Service');
Reproduce code:
---
new
HTML('a',array('href'=>'?action=addService&billed_services[account_id]='.
$_REQUEST['billed_services']['account_id']?$_REQUEST['billed_services']['account_id']
: $_REQUEST['accounts']['id']),'Add Service');
Expected result:
array('href'=>'?action=addService&billed_services[account_id]='.either or
val)
Actual result:
--
array('href'=>NULL)
--
Edit bug report at http://bugs.php.net/?id=33921&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33921&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33921&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33921&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33921&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33921&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33921&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33921&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33921&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33921&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33921&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33921&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33921&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33921&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33921&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33921&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33921&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33921&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33921&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33921&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33921&r=mysqlcfg
#32935 [Fbk->Opn]: SNMP timeouts on specific OIDs and truncating of certain OID return strings
ID: 32935
User updated by: nospam-php at homeuseonly dot co dot uk
Reported By: nospam-php at homeuseonly dot co dot uk
-Status: Feedback
+Status: Open
Bug Type: SNMP related
Operating System: Windows 2003 SP1 / Windows XP SP
PHP Version: 5CVS-2005-07-04
New Comment:
I have upgraded to the Windows CVS snapshot, but I am still getting
truncated output.
?php
print_R(snmpwalk("192.168.253.10","public",
".1.3.6.1.2.1.25.4.2.1.4"));
?>
gives me:
Array ( [0] => "" [1] => "" [2] => "C:\\WINDOWS" [3] => "C:\\Program
Files\\Microsoft Office\\OFFICE" [4] => "\\SystemRoot\\System3" [5] =>
"C:\\WINDOWS\\system3" [6] => "" [7] => "C:\\WINDOWS\\system3" [8] =>
"C:\\WINDOWS\\system3" [9] => "C:\\WINDOWS\\system3" [10] =>
"C:\\WINDOWS\\system3" [11] => "C:\\WINDOWS\\System3" [12] =>
"C:\\WINDOWS\\system3" [13] => "C:\\WINDOWS\\System3" [14] =>
"C:\\PROGRA~1\\Grisoft\\AV" [15] => "C:\\WINDOWS\\system3" [16] =>
"C:\\WINDOWS\\system3" [17] => "C:\\PROGRA~1\\Grisoft\\AV" [18] =>
"C:\\Program Files\\Alcohol Soft\\Alcohol 1" [19] => "C:\\WINDOWS\
.SNIP
Previous Comments:
[2005-07-29 18:16:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-04 09:52:13] nospam-php at homeuseonly dot co dot uk
I downlaoded the Windows version, V5.1.0-dev, as sugested, but I still
have the same problem.
This has been tested on Windows 2003 SP1, running Apache 2.0.54
[2005-07-04 01:04:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-05-12 09:29:24] nospam-php at homeuseonly dot co dot uk
The chunk of PHP code displays and array to the screen.
This array should contain the full results of a snmpwalk against
".1.3.6.1.2.1.25.4.2.1.4" but it appears that the output is being
truncated.
However when a running snmpwalk (snmpwalk -v 1 -c public 192.168.253.13
.1.3.6.1.2.1.25.4.2.1.4)
the output is correct.
Here is the part of the result for the SNMPWALK net-snmp command.
### START
HOST-RESOURCES-MIB::hrSWRunPath.1 = ""
HOST-RESOURCES-MIB::hrSWRunPath.4 = ""
HOST-RESOURCES-MIB::hrSWRunPath.136 = STRING:
"C:\\WINDOWS\\System32\\"
HOST-RESOURCES-MIB::hrSWRunPath.272 = STRING: "C:\\Program
Files\\Internet Explorer\\"
HOST-RESOURCES-MIB::hrSWRunPath.280 = STRING: "C:\\Program
Files\\Promise Technology, Inc.\\Promise Array Management\\"
HOST-RESOURCES-MIB::hrSWRunPath.336 = STRING: "C:\\Program
Files\\Promise Technology, Inc.\\Promise Array Management\\"
HOST-RESOURCES-MIB::hrSWRunPath.416 = STRING: "C:\\WINDOWS\\"
HOST-RESOURCES-MIB::hrSWRunPath.460 = STRING:
"C:\\WINDOWS\\system32\\"
HOST-RESOURCES-MIB::hrSWRunPath.496 = STRING:
"C:\\WINDOWS\\system32\\"
HOST-RESOURCES-MIB::hrSWRunPath.508 = STRING:
"C:\\PROGRA~1\\Grisoft\\AVG7\\"
### END
[2005-05-03 23:24:35] nospam-php at homeuseonly dot co dot uk
Description:
When running making specific SNMP get/walks against Windows 2003 or
Windows XP the following has been seen to occur
1. Sometimes the SNMP walk against .1.3.6.1.2.1.25.2.3 the request
times out. If I use GetIf to walk the OID the results are displayed,
but PHP fails randomly
2. When viewing .1.3.6.1.2.1.25.4.2.1.4 with GetIf the file
paths/names are displayed in full, but when I do a SNMP walk the output
is truncated.
Reproduce code:
---
The code can be downloaded from
http://sourceforge.net/users/lsms-mrtg/
The example windows code is in the package.
Example of the truncated output
Expected result:
The full program paths displayed, where appropriate.
Actual result:
--
Array ( [0] => "" [1] => "" [2] => "C:\\Program Files\\Promise
Technology, Inc.\\Promise Array Manageme" [3] => "" [4] => "" [5] =>
"C:\\users\\isms\\l" [6] => "" [7] => "C:\\WINDOWS\\System3" [8] =>
"C:\\users\\isms\\l" [9] => "\\SystemRoot\\System3" [10] => "" [11] =>
"c:\\squid\\sbi" [12] => "C:\\WINDOWS\\system3" [13] => "" [14] =>
"C:\\WINDOWS\\system3" [15] => "C:\\WINDOWS\\System3" [16] =>
"C:\\WINDOWS\\system3" [17] => "C:\\WINDOWS\\system3" [18] =>
"C:\\WINDOWS\\system3" [19] => "C:\\users\\isms\\l" [20] => "C:\\FS3"
[21] => "" [22] => "" [23] => "" [24] => "" [25] =>
"C:\\WINDOWS\\System3" [26] => "C:\\WINDOWS\\system3" [27] =>
"C:\\WINDOWS\\system3" [28] => "" [29] => "C:\\Program
Files\\TightVNC-unstabl" [30] => "C:\\PROGRA
#27688 [Asn->Bgs]: Session names consisting of only numbers cause session id generation
ID: 27688
Updated by: [EMAIL PROTECTED]
Reported By: ryan at daelibs dot com dot au
-Status: Assigned
+Status: Bogus
Bug Type: Session related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-01-10)
Assigned To: amt
New Comment:
Session name can NOT be a plain number.
No checks will be added since that'd make the code slower for no real
gain.
Previous Comments:
[2004-03-29 09:39:15] [EMAIL PROTECTED]
This happens because PHP turns a numeric session name
into an array index inside $_COOKIE and we're doing an
zend_hash_find() instead of a zend_hash_index_find().
(ext/session/session.c, line 1098).
We can probably fix the bug by doing a
zend_hash_index_find() instead if the session name
successfully converts to a integer.
[2004-03-29 04:53:03] unknown at simplemachines dot org
Here's a simple workaround:
Session ID: ', session_id(), '
Cookie: ', $_COOKIE[session_name()];
?>
Removing the session_id() line though, shows that the cookie is still
being properly set.
-[Unknown]
[2004-03-25 00:00:26] ryan at daelibs dot com dot au
Description:
When you use a session name that has only numbers, each call to
session_start seems to regenerate a new session id, so the session does
not persist.
The code below can be loaded and refreshed to reproduce the behaviour
Reproduce code:
---
';
echo 'Session Id: '.session_id().'';
?>
Expected result:
Session Name: 99
Session Id: {{a sid that remains the same between each refresh }}
Actual result:
--
Session Name: 99
Session Id: {{a different sid each refresh}}
--
Edit this bug report at http://bugs.php.net/?id=27688&edit=1
#27814 [Opn->Asn]: Multiple small packets send for HTTP request
ID: 27814 Updated by: [EMAIL PROTECTED] Reported By: Olaf at XCC dot TMFWeb dot NL -Status: Open +Status: Assigned Bug Type: HTTP related Operating System: * PHP Version: 5.1* Assigned To: wez New Comment: Still considering after over a year or is this fixed by now? (should this actually be a feature request?) Previous Comments: [2004-04-19 06:38:09] [EMAIL PROTECTED] It's too late for the 5.0 branch (which is in final RC stage), but it's under consideration for the 5.1 branch. [2004-04-19 03:02:02] OvdSpek at LIACS dot NL Will a buffer be added? [2004-03-31 17:55:02] [EMAIL PROTECTED] You're correct; there is no write buffering for the http request. [2004-03-31 14:48:37] Olaf at XCC dot TMFWeb dot NL Description: This code sends two packets, one of 16 bytes and one of 17 bytes. I guess this is caused by multiple calls to php_stream_write in http_fopen_wrapper.c: php_stream_url_wrap_http_ex Preparing the entire request in one buffer and sending it via one call should produce less packets (and be faster). Reproduce code: --- http://php.net/";)); ?> Expected result: One packet of 33 bytes. Actual result: -- Two packets. -- Edit this bug report at http://bugs.php.net/?id=27814&edit=1
#27814 [Asn->Opn]: Multiple small packets send for HTTP request
ID: 27814 Updated by: [EMAIL PROTECTED] Reported By: Olaf at XCC dot TMFWeb dot NL -Status: Assigned +Status: Open Bug Type: HTTP related Operating System: * PHP Version: 5.1* Assigned To: wez Previous Comments: [2004-04-19 06:38:09] [EMAIL PROTECTED] It's too late for the 5.0 branch (which is in final RC stage), but it's under consideration for the 5.1 branch. [2004-04-19 03:02:02] OvdSpek at LIACS dot NL Will a buffer be added? [2004-03-31 17:55:02] [EMAIL PROTECTED] You're correct; there is no write buffering for the http request. [2004-03-31 14:48:37] Olaf at XCC dot TMFWeb dot NL Description: This code sends two packets, one of 16 bytes and one of 17 bytes. I guess this is caused by multiple calls to php_stream_write in http_fopen_wrapper.c: php_stream_url_wrap_http_ex Preparing the entire request in one buffer and sending it via one call should produce less packets (and be faster). Reproduce code: --- http://php.net/";)); ?> Expected result: One packet of 33 bytes. Actual result: -- Two packets. -- Edit this bug report at http://bugs.php.net/?id=27814&edit=1
#33914 [Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914
Updated by: [EMAIL PROTECTED]
Reported By: me at thomaskeller dot biz
Status: Bogus
Bug Type: GD related
Operating System: Linux 2.4 shared hosting
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
Again it's not a bug.
You have to set the transparent color correctly in the destination
image.
--Pierre
Previous Comments:
[2005-07-29 18:12:15] [EMAIL PROTECTED]
RTFM: http://www.php.net/imagecolortransparent
[2005-07-29 17:36:48] me at thomaskeller dot biz
I have already provided a sample script, which is available on
http://thomaskeller.biz/work/php/PHP_GIF/image.php, the source for this
file is http://thomaskeller.biz/work/php/PHP_GIF/image.phps [0].
The test image which fails to be scaled is
http://thomaskeller.biz/work/php/PHP_GIF/rose.gif
As you can see here [0] the problematic code seems to be (shortened):
-1) // transparent color found?
{
list($r, $g, $b) = imagecolorsforindex($im_src,$idx);
$transColor = imagecolorexact($im_target, $r, $g, $b);
imagecolortransparent($im_target, $transColor);
}
?>
where I try to receive the index of the transparent color
of the original image, then find the rgb value of this color and
finally create a new color on the target image using the rgb value and
set it as transparent color.
[2005-07-29 17:19:21] [EMAIL PROTECTED]
Provide a sample (and little) script and the images causing your
problem may help.
For what you said, the "random" color may in fact be the background.
You have to set the transparent color yourself to the dest image.
Short version, it's not a bug as far as I can tell now.
I keep this bug to bogus, if you have a reproducable script with one
image, turn it back to open.
[2005-07-29 02:37:12] me at thomaskeller dot biz
Description:
Following use case:
Uploaded images should be shrinked to a certain size according to our
guidelines.
Works with jpeg/ png (not palette based) images without a problem,
problems arise when used palette based (8bit) images. Resizing via
imagecopyresampled/ imagecopyresize works only for images WITHOUT a
transparency color set properly. If a transparency color is set in the
image, the value of this color is just ignored and a random background
color is applied to the "transparent" area. It makes no difference if
the image is outputted as gif or 8bit png.
If imagecopyresampled/imagecopyresized is called with the same
width/height for the source and the target image, the transparency
keeps intact.
Reproduce code:
---
I've setuped a few things on a test server:
PHPInfo:
http://thomaskeller.biz/work/php/PHP_GIF/info.php
Testfile:
http://thomaskeller.biz/work/php/PHP_GIF/image.php
Testfile (Source):
http://thomaskeller.biz/work/php/PHP_GIF/image.phps
image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by
default, but you can load an own gif file via URL like
image.php?filename=http://your.server.com/file.gif
The loaded image is per default resized to its double width/ height.
--
Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#32935 [Opn->Fbk]: SNMP timeouts on specific OIDs and truncating of certain OID return strings
ID: 32935 Updated by: [EMAIL PROTECTED] Reported By: nospam-php at homeuseonly dot co dot uk -Status: Open +Status: Feedback Bug Type: SNMP related Operating System: Windows 2003 SP1 / Windows XP SP PHP Version: 5CVS-2005-07-04 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-07-04 09:52:13] nospam-php at homeuseonly dot co dot uk I downlaoded the Windows version, V5.1.0-dev, as sugested, but I still have the same problem. This has been tested on Windows 2003 SP1, running Apache 2.0.54 [2005-07-04 01:04:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-05-12 09:29:24] nospam-php at homeuseonly dot co dot uk The chunk of PHP code displays and array to the screen. This array should contain the full results of a snmpwalk against ".1.3.6.1.2.1.25.4.2.1.4" but it appears that the output is being truncated. However when a running snmpwalk (snmpwalk -v 1 -c public 192.168.253.13 .1.3.6.1.2.1.25.4.2.1.4) the output is correct. Here is the part of the result for the SNMPWALK net-snmp command. ### START HOST-RESOURCES-MIB::hrSWRunPath.1 = "" HOST-RESOURCES-MIB::hrSWRunPath.4 = "" HOST-RESOURCES-MIB::hrSWRunPath.136 = STRING: "C:\\WINDOWS\\System32\\" HOST-RESOURCES-MIB::hrSWRunPath.272 = STRING: "C:\\Program Files\\Internet Explorer\\" HOST-RESOURCES-MIB::hrSWRunPath.280 = STRING: "C:\\Program Files\\Promise Technology, Inc.\\Promise Array Management\\" HOST-RESOURCES-MIB::hrSWRunPath.336 = STRING: "C:\\Program Files\\Promise Technology, Inc.\\Promise Array Management\\" HOST-RESOURCES-MIB::hrSWRunPath.416 = STRING: "C:\\WINDOWS\\" HOST-RESOURCES-MIB::hrSWRunPath.460 = STRING: "C:\\WINDOWS\\system32\\" HOST-RESOURCES-MIB::hrSWRunPath.496 = STRING: "C:\\WINDOWS\\system32\\" HOST-RESOURCES-MIB::hrSWRunPath.508 = STRING: "C:\\PROGRA~1\\Grisoft\\AVG7\\" ### END [2005-05-03 23:24:35] nospam-php at homeuseonly dot co dot uk Description: When running making specific SNMP get/walks against Windows 2003 or Windows XP the following has been seen to occur 1. Sometimes the SNMP walk against .1.3.6.1.2.1.25.2.3 the request times out. If I use GetIf to walk the OID the results are displayed, but PHP fails randomly 2. When viewing .1.3.6.1.2.1.25.4.2.1.4 with GetIf the file paths/names are displayed in full, but when I do a SNMP walk the output is truncated. Reproduce code: --- The code can be downloaded from http://sourceforge.net/users/lsms-mrtg/ The example windows code is in the package. Example of the truncated output Expected result: The full program paths displayed, where appropriate. Actual result: -- Array ( [0] => "" [1] => "" [2] => "C:\\Program Files\\Promise Technology, Inc.\\Promise Array Manageme" [3] => "" [4] => "" [5] => "C:\\users\\isms\\l" [6] => "" [7] => "C:\\WINDOWS\\System3" [8] => "C:\\users\\isms\\l" [9] => "\\SystemRoot\\System3" [10] => "" [11] => "c:\\squid\\sbi" [12] => "C:\\WINDOWS\\system3" [13] => "" [14] => "C:\\WINDOWS\\system3" [15] => "C:\\WINDOWS\\System3" [16] => "C:\\WINDOWS\\system3" [17] => "C:\\WINDOWS\\system3" [18] => "C:\\WINDOWS\\system3" [19] => "C:\\users\\isms\\l" [20] => "C:\\FS3" [21] => "" [22] => "" [23] => "" [24] => "" [25] => "C:\\WINDOWS\\System3" [26] => "C:\\WINDOWS\\system3" [27] => "C:\\WINDOWS\\system3" [28] => "" [29] => "C:\\Program Files\\TightVNC-unstabl" [30] => "C:\\PROGRA~1\\Grisoft\\AV" [31] => "C:\\users\\isms\\l" [32] => "C:\\Program Files\\Apache Group\\Apache2\\" [33] => "" [34] => "C:\\PROGRA~1\\Grisoft\\AV" [35] => "C:\\Program Files\\Promise Technology, Inc\\Promise Array Manageme" [36] => "C:\\PROGRA~1\\Grisoft\\AV" [37] => "C:\\WINDOWS\\system3" [38] => "C:\\users\\isms\\l" [39] => "" [40] => "C:\\WINDOWS\\System3" [41] => "C:\\users\\isms\\l" [42] => "" [43] => "C:\\FS3" [44] => "C:\\users\\isms\\l" [45] => "" [46] => "C:\\Program Files\\Promise Technology, Inc.\\Promise Array Manageme" [47] => "" [48] => "C:\\WINDOWS" [49] => "" [50] => "C:\\PROGRA~1\\Grisoft\\AV" [51] => "C:\\WINDOWS" [52] => "C:\\Program Files\\ASUS\\Pro" [53] => "C:\\WINDOWS\\system3" [54] => "C:\\Program Files\\ATI Technologies\\ATI Control Pan" [55] => "" [56] => "" [57] => "C:\\WINDOWS\\system32\\wb" [58] => "C:\\Program Files\\Apache Group\\Apache2\\" [59] => "C:\\FS3" [60] => "" [61] => "C:\\PROGRA~1\\HAUPPA~" [62] => ""
#33747 [Opn->Asn]: php5: Too many Oracle-Sessions on INSERT Statements
ID: 33747 Updated by: [EMAIL PROTECTED] Reported By: alfred dot trapp at tvi-services dot de -Status: Open +Status: Assigned Bug Type: OCI8 related Operating System: Linux PHP Version: 5CVS-2005-07-19 -Assigned To: +Assigned To: tony2001 Previous Comments: [2005-07-20 17:04:27] alfred dot trapp at tvi-services dot de I'm sorry about that, but for now i can't provide such a script. I tried it with a short script on a test table with inserting 500 numeric values into one column only and could not reproduce the mentioned bug. Maybe you are right and it is a duplicate to bug #32361. I will watch furthermore to proposals concerning that bug and may be able to prepare a script that reproduces my problem. Thanks for trying to help. [2005-07-20 15:18:39] [EMAIL PROTECTED] As far as I understand it doesn't depend on the table, am I right? So why not to provide a script that CREATEs the table, INSERTs data into it and demonstrates the problem? Basically, what I want is a script that I can copy, paste, run and see the problem. That's all. Without all those variables that doesn't exist in the script, without non-existent tables etc. It's so easy, why do I need to ask you several times about it? Also, are you sure that ONLY THIS script causes the issue? If you just replace it with simple , , );?> - doesn't it behave in the same wrong way? It looks like another one duplicate of bug #32361, but you're talking about INSERTs for some reason. [2005-07-20 15:05:55] alfred dot trapp at tvi-services dot de $connection=ocilogon($user, $pwd, $sid); $tablename="RESULT"; for($i=0;$i>not more than 20 lines of code<<. If you want to know how the result array gets filled, i have to send you the whole script. [2005-07-20 14:41:41] [EMAIL PROTECTED] Obviously this code won't work as nobody knows where do you get $result & $tabinsert. [2005-07-20 14:36:54] alfred dot trapp at tvi-services dot de Hi tony Simplified Program Code $connection=ocilogon($user, $pwd, $sid); $tablename="RESULT_".$user; for($i=0;$ihttp://bugs.php.net/33747 -- Edit this bug report at http://bugs.php.net/?id=33747&edit=1
#33920 [Opn->Bgs]: Wrong shows hour
ID: 33920 Updated by: [EMAIL PROTECTED] Reported By: php-work at yandex dot ru -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows XP SP2 PHP Version: 5CVS-2005-07-29 (dev) New Comment: Set the timezone in php.ini using date.timezone setting. Previous Comments: [2005-07-29 16:37:50] php-work at yandex dot ru Description: Code: print Fri, 29 Jul 2005 14:22:56 +, but stated time zone: (GMT+03:00) Moscow. I tried to use other time zone, setlocale, but result is not changed. -- Edit this bug report at http://bugs.php.net/?id=33920&edit=1
#33884 [Opn->Bgs]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
Updated by: [EMAIL PROTECTED]
Reported By: php-bug-33884 at ryandesign dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
Previous Comments:
[2005-07-27 17:04:52] php-bug-33884 at ryandesign dot com
Thank you for your response.
I already checked the documentation on functions returning
by reference and could not find any indication that such
functions must always return something. If this is the case,
then this should be documented. If it already is documented,
I would appreciate a direct link to the relevant page.
I have many years of experience in software development,
software testing and bug reporting, and did not think my bug
report had been filed improperly. If you have specific
suggestions for how I could make future bug reports more
useful to you, by all means please share them with me.
Truly, if my function never returned anything, then as you
say I would not need to declare the it as return-by-
reference. However, I do sometimes need to return a
reference. Therefore the function must be declared in this
way. Here is a more concrete example of what my function
does:
class foo {
function &get_or_set($bar, $baz = null) {
if ($baz) {
$GLOBALS['qux'][$bar] =& $baz;
} else {
return $GLOBALS['qux'][$bar];
}
}
}
In this particular case, I can avoid the error by modifying
the code so that the "else" part occurs unconditionally. I
just couldn't see any reason to require that a return-by-
reference function must return a value, when return-by-copy
functions are not restricted in this manner. If such a
reason exists, please enlighten me.
[2005-07-27 16:14:27] [EMAIL PROTECTED]
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
If you don\'t return anything you don\'t need
return-by-reference...
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33914 [Fbk->Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914
Updated by: [EMAIL PROTECTED]
Reported By: me at thomaskeller dot biz
-Status: Feedback
+Status: Bogus
Bug Type: GD related
Operating System: Linux 2.4 shared hosting
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
.
Previous Comments:
[2005-07-29 18:12:15] [EMAIL PROTECTED]
RTFM: http://www.php.net/imagecolortransparent
[2005-07-29 17:36:48] me at thomaskeller dot biz
I have already provided a sample script, which is available on
http://thomaskeller.biz/work/php/PHP_GIF/image.php, the source for this
file is http://thomaskeller.biz/work/php/PHP_GIF/image.phps [0].
The test image which fails to be scaled is
http://thomaskeller.biz/work/php/PHP_GIF/rose.gif
As you can see here [0] the problematic code seems to be (shortened):
-1) // transparent color found?
{
list($r, $g, $b) = imagecolorsforindex($im_src,$idx);
$transColor = imagecolorexact($im_target, $r, $g, $b);
imagecolortransparent($im_target, $transColor);
}
?>
where I try to receive the index of the transparent color
of the original image, then find the rgb value of this color and
finally create a new color on the target image using the rgb value and
set it as transparent color.
[2005-07-29 17:19:21] [EMAIL PROTECTED]
Provide a sample (and little) script and the images causing your
problem may help.
For what you said, the "random" color may in fact be the background.
You have to set the transparent color yourself to the dest image.
Short version, it's not a bug as far as I can tell now.
I keep this bug to bogus, if you have a reproducable script with one
image, turn it back to open.
[2005-07-29 02:37:12] me at thomaskeller dot biz
Description:
Following use case:
Uploaded images should be shrinked to a certain size according to our
guidelines.
Works with jpeg/ png (not palette based) images without a problem,
problems arise when used palette based (8bit) images. Resizing via
imagecopyresampled/ imagecopyresize works only for images WITHOUT a
transparency color set properly. If a transparency color is set in the
image, the value of this color is just ignored and a random background
color is applied to the "transparent" area. It makes no difference if
the image is outputted as gif or 8bit png.
If imagecopyresampled/imagecopyresized is called with the same
width/height for the source and the target image, the transparency
keeps intact.
Reproduce code:
---
I've setuped a few things on a test server:
PHPInfo:
http://thomaskeller.biz/work/php/PHP_GIF/info.php
Testfile:
http://thomaskeller.biz/work/php/PHP_GIF/image.php
Testfile (Source):
http://thomaskeller.biz/work/php/PHP_GIF/image.phps
image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by
default, but you can load an own gif file via URL like
image.php?filename=http://your.server.com/file.gif
The loaded image is per default resized to its double width/ height.
--
Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33914 [Opn->Fbk]: Resizing palette based images with transparency bit loose transparency
ID: 33914
Updated by: [EMAIL PROTECTED]
Reported By: me at thomaskeller dot biz
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Linux 2.4 shared hosting
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
RTFM: http://www.php.net/imagecolortransparent
Previous Comments:
[2005-07-29 17:36:48] me at thomaskeller dot biz
I have already provided a sample script, which is available on
http://thomaskeller.biz/work/php/PHP_GIF/image.php, the source for this
file is http://thomaskeller.biz/work/php/PHP_GIF/image.phps [0].
The test image which fails to be scaled is
http://thomaskeller.biz/work/php/PHP_GIF/rose.gif
As you can see here [0] the problematic code seems to be (shortened):
-1) // transparent color found?
{
list($r, $g, $b) = imagecolorsforindex($im_src,$idx);
$transColor = imagecolorexact($im_target, $r, $g, $b);
imagecolortransparent($im_target, $transColor);
}
?>
where I try to receive the index of the transparent color
of the original image, then find the rgb value of this color and
finally create a new color on the target image using the rgb value and
set it as transparent color.
[2005-07-29 17:19:21] [EMAIL PROTECTED]
Provide a sample (and little) script and the images causing your
problem may help.
For what you said, the "random" color may in fact be the background.
You have to set the transparent color yourself to the dest image.
Short version, it's not a bug as far as I can tell now.
I keep this bug to bogus, if you have a reproducable script with one
image, turn it back to open.
[2005-07-29 02:37:12] me at thomaskeller dot biz
Description:
Following use case:
Uploaded images should be shrinked to a certain size according to our
guidelines.
Works with jpeg/ png (not palette based) images without a problem,
problems arise when used palette based (8bit) images. Resizing via
imagecopyresampled/ imagecopyresize works only for images WITHOUT a
transparency color set properly. If a transparency color is set in the
image, the value of this color is just ignored and a random background
color is applied to the "transparent" area. It makes no difference if
the image is outputted as gif or 8bit png.
If imagecopyresampled/imagecopyresized is called with the same
width/height for the source and the target image, the transparency
keeps intact.
Reproduce code:
---
I've setuped a few things on a test server:
PHPInfo:
http://thomaskeller.biz/work/php/PHP_GIF/info.php
Testfile:
http://thomaskeller.biz/work/php/PHP_GIF/image.php
Testfile (Source):
http://thomaskeller.biz/work/php/PHP_GIF/image.phps
image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by
default, but you can load an own gif file via URL like
image.php?filename=http://your.server.com/file.gif
The loaded image is per default resized to its double width/ height.
--
Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33904 [Ctl->Csd]: magic quotes added to posted array keys even when magic_quotes_gpc is off
ID: 33904 Updated by: [EMAIL PROTECTED] Reported By: php at kanariepiet dot com -Status: Critical +Status: Closed Bug Type: *General Issues Operating System: * PHP Version: 5CVS-2005-07-29 Previous Comments: [2005-07-28 17:20:03] [EMAIL PROTECTED] See also bug #29165. [2005-07-28 17:04:23] php at kanariepiet dot com php5-200507281430 gives the same results as php-5.0.4: returns Array ( [foo\'bar] => bar'foo ) [2005-07-28 16:34:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-28 16:30:33] php at kanariepiet dot com phpinfo() show that magic quotes are turned off. As stated above, value parts are left alone. The following code returns Array ( [test] => foo'bar ) as expected, so the settings are ok. [2005-07-28 16:26:57] php at kanariepiet dot com To be more precies: The quotes in the value parts of the $_POST array are left alone (good), but the quotes in the key parts of the $_POST array are preceeded with slashes (wrong). 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/33904 -- Edit this bug report at http://bugs.php.net/?id=33904&edit=1
#33643 [Com]: Fatal error: Only variables can be passed by reference
ID: 33643
Comment by: leakim at nollipap dot com
Reported By: Jason at hybd dot net
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS-2005-07-18
Assigned To: derick
New Comment:
Bug reproduced with MamboV4[1].5.2.3-stable.tar.gz after upgrade from
php-4.3.11-Win32.zip
to
php-5.1.0b3-Win32.zip
Fatal error: Only variables can be passed by reference in
c:\Apache\htdocs\site\administrator\components\com_content\admin.content.php
on line 472
where line 472 is :
$lists['sectionid'] = mosHTML::selectList( $database->loadObjectList(),
'sectionid', 'class="inputbox" size="1" '. $javascript, 'value', 'text',
intval( $row->sectionid) );
Bug go out replacing the line by :
$ol = $database->loadObjectList();
$lists['sectionid'] = mosHTML::selectList( $database->loadObjectList(),
'sectionid', 'class="inputbox" size="1" '. $javascript, 'value', 'text',
intval( $row->sectionid) );
Previous Comments:
[2005-07-14 16:37:02] [EMAIL PROTECTED]
This sort of thing needs to throw an error in any version of PHP I
think:
function foo() { return "blah"; }
function bar(&$arg) { $arg = 1; }
bar(foo());
While this should work:
function & foo() { static $a; return $a; }
function bar(&$arg) { $arg = 1; }
bar(foo());
And it does in PHP5.1 at least. The first case indicates a clear bug
in the code that we really should be catching. I suppose we could
compromise and throw a warning in PHP4 and then fall back to passing
the argument by value, but that is changing the actual workings of the
script and is likely going to be wrong. I think this needs to be part
of the reference fixes in PHP4.4. Sucks that it wasn't caught before
the 4.4.0 release, but that's the way it goes.
[2005-07-14 13:06:00] [EMAIL PROTECTED]
The "Fatal error:" in HEAD and PHP_5_0 occurs because of fix for bug
#33257. The patch was not applied into PHP 4.4 because it wasn't
affected by this bug (PHP 4 doesn't allow static properties).
Now I found reproducable case for PHP_4_4. :(
Expected result:
Fatal error: Only variables can be passed by reference
Or:
---
foo
foo
bar
bar
Actual result:
--
foo
bar
bar
The current behavoir of HEAD is proper from my point of view. PHP_4_4
may be fixed but it will break BC again.
Derick, Andi?
[2005-07-14 11:16:56] [EMAIL PROTECTED]
I think we need to discuss this a bit more, PHP 4.4 indeed gives no
warning or notice on this. Andi, Dmitry?
[2005-07-14 11:01:13] [EMAIL PROTECTED]
Actual result (4.x after removing "public static"):
4.3.10: No error
4.4.0: No error
5.0.4: No error
5.1.0: Fatal error
Is this really the expected result? I thought 4.4.0 should produce
something too. In which cases 4.4.0 produces errors?
[2005-07-11 13:06:46] Jason at hybd dot net
Description:
This bug is a rehash of 33516, but I can't reopen as I'm not the
original author.
It seems like you can not pass tempories to function / method
parameters.
'1234567890');
}
}
$tmp = Foo::bar();
$var = array_pop($tmp);
?>
Seems to work, but it shouldn't be down to the PHP user (imho) to
implement this as this change in PHP 5.1 breaks a lot of existing code.
Reproduce code:
---
'1234567890');
}
}
$var = array_pop(Foo::bar());
?>
Expected result:
$var = '1234567890';
Foo::bar() gets placed in temporary variable
Actual result:
--
Fatal error: Only variables can be passed by reference
--
Edit this bug report at http://bugs.php.net/?id=33643&edit=1
#33914 [Bgs->Opn]: Resizing palette based images with transparency bit loose transparency
ID: 33914
User updated by: me at thomaskeller dot biz
Reported By: me at thomaskeller dot biz
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Linux 2.4 shared hosting
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
I have already provided a sample script, which is available on
http://thomaskeller.biz/work/php/PHP_GIF/image.php, the source for this
file is http://thomaskeller.biz/work/php/PHP_GIF/image.phps [0].
The test image which fails to be scaled is
http://thomaskeller.biz/work/php/PHP_GIF/rose.gif
As you can see here [0] the problematic code seems to be (shortened):
-1) // transparent color found?
{
list($r, $g, $b) = imagecolorsforindex($im_src,$idx);
$transColor = imagecolorexact($im_target, $r, $g, $b);
imagecolortransparent($im_target, $transColor);
}
?>
where I try to receive the index of the transparent color
of the original image, then find the rgb value of this color and
finally create a new color on the target image using the rgb value and
set it as transparent color.
Previous Comments:
[2005-07-29 17:19:21] [EMAIL PROTECTED]
Provide a sample (and little) script and the images causing your
problem may help.
For what you said, the "random" color may in fact be the background.
You have to set the transparent color yourself to the dest image.
Short version, it's not a bug as far as I can tell now.
I keep this bug to bogus, if you have a reproducable script with one
image, turn it back to open.
[2005-07-29 13:36:34] me at thomaskeller dot biz
So, is this a bug in GD and you guys are not responsible or is it me
or... a small sentence below the auto responder may have helped.
[2005-07-29 10:47:50] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2005-07-29 02:37:12] me at thomaskeller dot biz
Description:
Following use case:
Uploaded images should be shrinked to a certain size according to our
guidelines.
Works with jpeg/ png (not palette based) images without a problem,
problems arise when used palette based (8bit) images. Resizing via
imagecopyresampled/ imagecopyresize works only for images WITHOUT a
transparency color set properly. If a transparency color is set in the
image, the value of this color is just ignored and a random background
color is applied to the "transparent" area. It makes no difference if
the image is outputted as gif or 8bit png.
If imagecopyresampled/imagecopyresized is called with the same
width/height for the source and the target image, the transparency
keeps intact.
Reproduce code:
---
I've setuped a few things on a test server:
PHPInfo:
http://thomaskeller.biz/work/php/PHP_GIF/info.php
Testfile:
http://thomaskeller.biz/work/php/PHP_GIF/image.php
Testfile (Source):
http://thomaskeller.biz/work/php/PHP_GIF/image.phps
image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by
default, but you can load an own gif file via URL like
image.php?filename=http://your.server.com/file.gif
The loaded image is per default resized to its double width/ height.
--
Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33884 [Bgs->Opn]: "Only variable references should be returned by reference" if I return nothing
ID: 33884
User updated by: php-bug-33884 at ryandesign dot com
Reported By: php-bug-33884 at ryandesign dot com
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: N/A
PHP Version: 4.4.0
New Comment:
I wasn't sure if I was supposed to re-open the bug for you to
see my new comments.
Previous Comments:
[2005-07-27 17:04:52] php-bug-33884 at ryandesign dot com
Thank you for your response.
I already checked the documentation on functions returning
by reference and could not find any indication that such
functions must always return something. If this is the case,
then this should be documented. If it already is documented,
I would appreciate a direct link to the relevant page.
I have many years of experience in software development,
software testing and bug reporting, and did not think my bug
report had been filed improperly. If you have specific
suggestions for how I could make future bug reports more
useful to you, by all means please share them with me.
Truly, if my function never returned anything, then as you
say I would not need to declare the it as return-by-
reference. However, I do sometimes need to return a
reference. Therefore the function must be declared in this
way. Here is a more concrete example of what my function
does:
class foo {
function &get_or_set($bar, $baz = null) {
if ($baz) {
$GLOBALS['qux'][$bar] =& $baz;
} else {
return $GLOBALS['qux'][$bar];
}
}
}
In this particular case, I can avoid the error by modifying
the code so that the "else" part occurs unconditionally. I
just couldn't see any reason to require that a return-by-
reference function must return a value, when return-by-copy
functions are not restricted in this manner. If such a
reason exists, please enlighten me.
[2005-07-27 16:14:27] [EMAIL PROTECTED]
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
If you don\'t return anything you don\'t need
return-by-reference...
[2005-07-27 15:02:41] php-bug-33884 at ryandesign dot com
Description:
Hi. After upgrading from PHP 4.3.11 to 4.4.0 I get the
famous "Only variable references should be returned by
reference" notice in one of my projects. The function in
question returns by reference, but only needs to do this
sometimes. Other times, it returns nothing at all, because
the caller does not need a return value. In these latter
cases, PHP produces the notice as of 4.4.0.
This surprised me because it's perfectly fine to have a
normal return-by-copy function that does not return
anything. So why not a return-by-reference function?
I couldn't find any documentation that if your function
returns by reference, then you must always return something.
In my particular case I can rewrite the function so that it
always returns something, even when the caller has no use
for it. I just wasn't sure if the notice in this case was
intended, and if so, why.
If the behavior is intended, then the documentation should
reflect this.
Reproduce code:
---
error_reporting(E_ALL);
function &foo_by_reference_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function &foo_by_reference_without_return() {
echo __FUNCTION__ . "\n";
} // line 11
function foo_by_copy_with_return() {
echo __FUNCTION__ . "\n";
return $GLOBALS['bar'];
}
function foo_by_copy_without_return() {
echo __FUNCTION__ . "\n";
}
foo_by_reference_with_return();
foo_by_reference_without_return(); // causes notice in 4.4.0
foo_by_copy_with_return();
foo_by_copy_without_return();
Expected result:
foo_by_reference_with_return
foo_by_reference_without_return
foo_by_copy_with_return
foo_by_copy_without_return
Actual result:
--
foo_by_reference_with_return
foo_by_reference_without_return
Notice: Only variable references should be returned by
reference in references.php on line 11
foo_by_copy_with_return
foo_by_copy_without_return
--
Edit this bug report at http://bugs.php.net/?id=33884&edit=1
#33914 [Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914 Updated by: [EMAIL PROTECTED] Reported By: me at thomaskeller dot biz Status: Bogus Bug Type: GD related Operating System: Linux 2.4 shared hosting PHP Version: 4.3.11 -Assigned To: +Assigned To: pajoye New Comment: Provide a sample (and little) script and the images causing your problem may help. For what you said, the "random" color may in fact be the background. You have to set the transparent color yourself to the dest image. Short version, it's not a bug as far as I can tell now. I keep this bug to bogus, if you have a reproducable script with one image, turn it back to open. Previous Comments: [2005-07-29 13:36:34] me at thomaskeller dot biz So, is this a bug in GD and you guys are not responsible or is it me or... a small sentence below the auto responder may have helped. [2005-07-29 10:47:50] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2005-07-29 02:37:12] me at thomaskeller dot biz Description: Following use case: Uploaded images should be shrinked to a certain size according to our guidelines. Works with jpeg/ png (not palette based) images without a problem, problems arise when used palette based (8bit) images. Resizing via imagecopyresampled/ imagecopyresize works only for images WITHOUT a transparency color set properly. If a transparency color is set in the image, the value of this color is just ignored and a random background color is applied to the "transparent" area. It makes no difference if the image is outputted as gif or 8bit png. If imagecopyresampled/imagecopyresized is called with the same width/height for the source and the target image, the transparency keeps intact. Reproduce code: --- I've setuped a few things on a test server: PHPInfo: http://thomaskeller.biz/work/php/PHP_GIF/info.php Testfile: http://thomaskeller.biz/work/php/PHP_GIF/image.php Testfile (Source): http://thomaskeller.biz/work/php/PHP_GIF/image.phps image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by default, but you can load an own gif file via URL like image.php?filename=http://your.server.com/file.gif The loaded image is per default resized to its double width/ height. -- Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33920 [NEW]: Wrong shows hour
From: php-work at yandex dot ru Operating system: Windows XP SP2 PHP version: 5CVS-2005-07-29 (dev) PHP Bug Type: Date/time related Bug description: Wrong shows hour Description: Code: print Fri, 29 Jul 2005 14:22:56 +, but stated time zone: (GMT+03:00) Moscow. I tried to use other time zone, setlocale, but result is not changed. -- Edit bug report at http://bugs.php.net/?id=33920&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33920&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33920&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33920&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33920&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33920&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33920&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33920&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33920&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33920&r=support Expected behavior: http://bugs.php.net/fix.php?id=33920&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33920&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33920&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33920&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33920&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33920&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33920&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33920&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33920&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33920&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33920&r=mysqlcfg
#33916 [Asn->Csd]: Unknown MySQL server host '.'
ID: 33916
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: RH fedora, core 2
PHP Version: 5.0.4
Assigned To: wez
New Comment:
Upgrade them to 0.9; this was fixed long ago.
Previous Comments:
[2005-07-29 16:20:24] deadman_great at mail dot ru
PDO v0.3 & PDO_MySQL v0.2.
PS: I think that PDO is bundled in php 5.1.x, but I can't install it,
because zend optimizer won't work on it.
[2005-07-29 15:33:27] [EMAIL PROTECTED]
Please tell us which PDO/PDO_MYSQL versions you have in your PHP 5.0.4
install.
[2005-07-29 12:10:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 12:07:59] deadman_great at mail dot ru
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1
{main} thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=33916&edit=1
#33876 [Opn->Asn]: PDO misquotes/miscasts bool(false)
ID: 33876
Updated by: [EMAIL PROTECTED]
Reported By: php at sagi dot org
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5CVS-2005-07-27 (dev)
-Assigned To:
+Assigned To: wez
Previous Comments:
[2005-07-27 17:15:10] php at sagi dot org
For what it's worth, its seems like the pgsql _client_ library that my
installation is compiled against is v7.4.7, even though the server is
running v8.0.
So I guess it never used native prepared statements and the workaround
that you suggested had no affect - they're already disabled.
[2005-07-27 16:40:54] php at sagi dot org
Nope, still get the same exception and the same query is being executed
according to the server log.
Still using the same php5-200507261230 snapshot.
The exact code:
$res = $db->prepare(
'SELECT id,name,trial FROM shops WHERE trial = ?',
array(PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT =>
true)
);
$res->execute(array(false));
And the result:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""' in /home/shopy/dev/tmp/test.php:12
Stack trace:
#0 /home/shopy/dev/tmp/test.php(12): PDOStatement->execute(Array)
#1 {main}
thrown in /home/shopy/dev/tmp/test.php on line 12
[2005-07-27 16:25:22] [EMAIL PROTECTED]
Try this as a workaround for now:
$res = $db->prepare('SELECT ...', array(
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT => true
));
You can blame the pretty poor native prepared statement API in pgsql
for this one; it just doesn't tell PDO anything about the parameter
types so it can't make an informed decision about how to treat the
parameters.
[2005-07-27 15:56:26] php at sagi dot org
I know how string casting works, but this is not a string.
PDO knows, for example, how to convert PHP NULL to SQL NULL and not
string('') (like string casting does). Why can't it cast bool values to
an integer instead?
This behavior is bad. PDO knows how to cast the value to real php bool
when selecting, but cannot cast it back when inserting/updating, which
means a simple attempt to re-insert a row that has just been selected,
using the same object, fails.
[2005-07-27 15:16:02] [EMAIL PROTECTED]
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 expected behaviour, when cast to a string bool false is
converted to "" while bool true converted to "1".
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/33876
--
Edit this bug report at http://bugs.php.net/?id=33876&edit=1
#33916 [Opn->Asn]: Unknown MySQL server host '.'
ID: 33916
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: RH fedora, core 2
PHP Version: 5.0.4
-Assigned To:
+Assigned To: wez
Previous Comments:
[2005-07-29 16:20:24] deadman_great at mail dot ru
PDO v0.3 & PDO_MySQL v0.2.
PS: I think that PDO is bundled in php 5.1.x, but I can't install it,
because zend optimizer won't work on it.
[2005-07-29 15:33:27] [EMAIL PROTECTED]
Please tell us which PDO/PDO_MYSQL versions you have in your PHP 5.0.4
install.
[2005-07-29 12:10:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 12:07:59] deadman_great at mail dot ru
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1
{main} thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=33916&edit=1
#33915 [Opn->Fbk]: Crash in _oci_close_session
ID: 33915
Updated by: [EMAIL PROTECTED]
Reported By: jfbustarret at tf1 dot fr
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 5.0.4
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-07-29 16:15:34] jfbustarret at tf1 dot fr
The bug exists with the CVS version of ext/oci8.
[2005-07-29 09:56:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 08:25:19] jfbustarret at tf1 dot fr
Description:
Using php 5.0.4, with the oci8 extension from CVS & the oci_ping code
activated in _oci_open_server, I have random segfaults on my production
servers.
Here is the back trace :
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
2961CALL_OCI_RETURN(OCI(error),
(gdb) bt
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
#1 0xb79f0d5e in list_entry_destructor (ptr=0x83590f0)
at /soft/sources/php/php-5.0.4/Zend/zend_list.c:173
#2 0xb79eef48 in zend_hash_apply_deleter (ht=0xb7a72560, p=0x836a4c8)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:618
#3 0xb79ef227 in zend_hash_graceful_reverse_destroy (ht=0xb7a72560)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:684
#4 0xb79e144a in shutdown_executor ()
at /soft/sources/php/php-5.0.4/Zend/zend_execute_API.c:284
#5 0xb79e8c86 in zend_deactivate ()
at /soft/sources/php/php-5.0.4/Zend/zend.c:902
#6 0xb79b544c in php_request_shutdown (dummy=0x0)
[...]
(gdb) print *session
$1 = {num = 137800016, persistent = 0 '\0', is_open = 253 'ý',
exclusive = 49 '1', thread = 8 '\b', sessions_list = 0x0, server =
0x0,
pSession = 0x0, pEnv = 0x0, charsetId = 0}
I'll try this patch in _oci_close_session :
if (!session) {
return;
}
+if (!session->server) {
+return;
+}
oci_debug("START _oci_close_session: logging-off
sess=%d",session->num);
Reproduce code:
---
No reproducing code. The crashes are random & time/traffic dependant.
--
Edit this bug report at http://bugs.php.net/?id=33915&edit=1
#33916 [Fbk->Opn]: Unknown MySQL server host '.'
ID: 33916
User updated by: deadman_great at mail dot ru
Reported By: deadman_great at mail dot ru
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: RH fedora, core 2
PHP Version: 5.0.4
New Comment:
PDO v0.3 & PDO_MySQL v0.2.
PS: I think that PDO is bundled in php 5.1.x, but I can't install it,
because zend optimizer won't work on it.
Previous Comments:
[2005-07-29 15:33:27] [EMAIL PROTECTED]
Please tell us which PDO/PDO_MYSQL versions you have in your PHP 5.0.4
install.
[2005-07-29 12:10:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 12:07:59] deadman_great at mail dot ru
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1
{main} thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=33916&edit=1
#33915 [Fbk->Opn]: Crash in _oci_close_session
ID: 33915
User updated by: jfbustarret at tf1 dot fr
Reported By: jfbustarret at tf1 dot fr
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 5.0.4
New Comment:
The bug exists with the CVS version of ext/oci8.
Previous Comments:
[2005-07-29 09:56:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 08:25:19] jfbustarret at tf1 dot fr
Description:
Using php 5.0.4, with the oci8 extension from CVS & the oci_ping code
activated in _oci_open_server, I have random segfaults on my production
servers.
Here is the back trace :
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
2961CALL_OCI_RETURN(OCI(error),
(gdb) bt
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
#1 0xb79f0d5e in list_entry_destructor (ptr=0x83590f0)
at /soft/sources/php/php-5.0.4/Zend/zend_list.c:173
#2 0xb79eef48 in zend_hash_apply_deleter (ht=0xb7a72560, p=0x836a4c8)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:618
#3 0xb79ef227 in zend_hash_graceful_reverse_destroy (ht=0xb7a72560)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:684
#4 0xb79e144a in shutdown_executor ()
at /soft/sources/php/php-5.0.4/Zend/zend_execute_API.c:284
#5 0xb79e8c86 in zend_deactivate ()
at /soft/sources/php/php-5.0.4/Zend/zend.c:902
#6 0xb79b544c in php_request_shutdown (dummy=0x0)
[...]
(gdb) print *session
$1 = {num = 137800016, persistent = 0 '\0', is_open = 253 'ý',
exclusive = 49 '1', thread = 8 '\b', sessions_list = 0x0, server =
0x0,
pSession = 0x0, pEnv = 0x0, charsetId = 0}
I'll try this patch in _oci_close_session :
if (!session) {
return;
}
+if (!session->server) {
+return;
+}
oci_debug("START _oci_close_session: logging-off
sess=%d",session->num);
Reproduce code:
---
No reproducing code. The crashes are random & time/traffic dependant.
--
Edit this bug report at http://bugs.php.net/?id=33915&edit=1
#33918 [Opn->Csd]: File uploads: apostrophes cause filename to be incorrectly reported
ID: 33918
Updated by: [EMAIL PROTECTED]
Reported By: lewis dot peckover at m-w dot co dot uk
-Status: Open
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: all?
PHP Version: 5.0.4
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-07-29 15:08:29] lewis dot peckover at m-w dot co dot uk
Description:
Any file uploaded that has a name containing an apostrophe ('), eg
foo'bar.txt, will be incorrectly named in the $_FILES array. It will
ignore all characters up to and including the apostrophe.
foo'bar.txt -> bar.txt
Tested on PHP 4.3.10/Apache/FreeBSD 5.3 and PHP 5.0.4/IIS/Windows 2003.
Reproduce code:
---
Expected result:
Array
(
[file] => Array
(
[name] => foo'bar.txt
[type] => text/plain
[tmp_name] => d:\PHP\uploadtemp\php9B1.tmp
[error] => 0
[size] => 9
)
)
Actual result:
--
Array
(
[file] => Array
(
[name] => bar.txt
[type] => text/plain
[tmp_name] => d:\PHP\uploadtemp\php9B1.tmp
[error] => 0
[size] => 9
)
)
--
Edit this bug report at http://bugs.php.net/?id=33918&edit=1
#33919 [Opn->Fbk]: Wrong timestamp return
ID: 33919
Updated by: [EMAIL PROTECTED]
Reported By: gustavog at dextra dot com dot br
-Status: Open
+Status: Feedback
-Bug Type: Calendar related
+Bug Type: Date/time related
Operating System: debian-sarge
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-07-29 15:21:09] gustavog at dextra dot com dot br
Description:
When I user the function strtotime on february, I get a wrong
timestamp.
Reproduce code:
---
$timestamp = strtotime("1 february 2005");
$timestamp = strtotime("2 Monday", $timestamp);
//No problem display "14-02-2005 -- Monday"
echo date("d-m-Y -- l ", $timestamp);
echo "";
$timestamp = strtotime("1 february 2005");
$timestamp = strtotime("3 Monday", $timestamp);
//Display 20-02-2005 -- Sunday instead of 21-02-2005 -- Monday
echo date("d-m-Y -- l ", $timestamp);
Expected result:
The second echo command should display the third Monday of february,
but it displays Sunday.
--
Edit this bug report at http://bugs.php.net/?id=33919&edit=1
#33899 [Opn->Csd]: setting both extension_dir and extension= on command line doesn't work
ID: 33899
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Dynamic loading
Operating System: linux
PHP Version: 5CVS-2005-07-28 (dev)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-07-28 12:32:35] [EMAIL PROTECTED]
ext/standard/dl.c has the following code in php_dl():
if (type==MODULE_PERSISTENT) {
/* Use the configuration hash directly, the INI mechanism is
not yet
initialized */
if (cfg_get_string("extension_dir", &extension_dir)==FAILURE) {
extension_dir = PHP_EXTENSION_DIR;
}
} else {
extension_dir = PG(extension_dir);
}
extensions loaded from command line take the MODULE_PERSISTANT path but
debug output shows that PG(extension_dir) shows the new extension_dir
set by the command line option just fine ...
[2005-07-28 12:30:52] [EMAIL PROTECTED]
Description:
I try to test a newly created PECL extension, the extension shared
object file has been created in ./modules/myext.so
when i do a "make install" to copy the myext.so to the default
extension
directory first i can load it just fine using either "php -d
'extension=myext.so'"
or using dl("myext.so"); within my code
when i start php with "php -d 'extension_dir=./modules'" i can use
dl("myext.so"); within my code just fine, too. the extension is loaded
from ./modules as expected
but when i try to use both commandline options
php -d 'extension_dir=./modules' -d 'extension=myext.so'
myext.so is either loaded from the default extension_dir,
not ./modules, or it is not loaded at all if not present in the
default extension dir
Expected result:
-d 'extension_dir=...' should take effect right away if given on the
command line, even for following -d 'extension=...' options
--
Edit this bug report at http://bugs.php.net/?id=33899&edit=1
#33919 [NEW]: Wrong timestamp return
From: gustavog at dextra dot com dot br
Operating system: debian-sarge
PHP version: 5.0.4
PHP Bug Type: Calendar related
Bug description: Wrong timestamp return
Description:
When I user the function strtotime on february, I get a wrong timestamp.
Reproduce code:
---
$timestamp = strtotime("1 february 2005");
$timestamp = strtotime("2 Monday", $timestamp);
//No problem display "14-02-2005 -- Monday"
echo date("d-m-Y -- l ", $timestamp);
echo "";
$timestamp = strtotime("1 february 2005");
$timestamp = strtotime("3 Monday", $timestamp);
//Display 20-02-2005 -- Sunday instead of 21-02-2005 -- Monday
echo date("d-m-Y -- l ", $timestamp);
Expected result:
The second echo command should display the third Monday of february, but
it displays Sunday.
--
Edit bug report at http://bugs.php.net/?id=33919&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33919&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33919&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33919&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33919&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33919&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33919&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33919&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33919&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33919&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33919&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33919&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33919&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33919&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33919&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33919&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33919&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33919&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33919&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33919&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33919&r=mysqlcfg
#32107 [NoF->Fbk]: fclose (STDIN|STDOUT|STDERR) not working
ID: 32107 Updated by: [EMAIL PROTECTED] Reported By: php at the-eend dot org -Status: No Feedback +Status: Feedback Bug Type: CGI related Operating System: Redhat ES3 PHP Version: 4.3.10 New Comment: Please try it with PHP 5 Previous Comments: [2005-07-29 13:01:57] Andreas dot Oesterhelt at InTradeSys dot com Here's the test case requested by [EMAIL PROTECTED]: Tested in PHP 4.3.10 (cli) [2005-03-20 18:01:30] [EMAIL PROTECTED] 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. [2005-02-25 14:09:02] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-02-25 13:33:10] php at the-eend dot org True enough, the resource goes from being a stream to an "Unknown". Unfortunately, my terminal still hangs until the script is complete when I try to log out of the server. If the stream is truly closed (not saying I don't believe you ;)), I guess it must be something else. :( I sense an incoming "bogus"... ;) [2005-02-25 13:03:46] [EMAIL PROTECTED] Why do you think they are not closed? Or use var_dump() in your example: 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/32107 -- Edit this bug report at http://bugs.php.net/?id=32107&edit=1
#33916 [Fbk]: Unknown MySQL server host '.'
ID: 33916
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
Status: Feedback
Bug Type: PDO related
Operating System: RH fedora, core 2
PHP Version: 5.0.4
New Comment:
Please tell us which PDO/PDO_MYSQL versions you have in your PHP 5.0.4
install.
Previous Comments:
[2005-07-29 12:10:40] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-29 12:07:59] deadman_great at mail dot ru
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1
{main} thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=33916&edit=1
#33918 [NEW]: File uploads: apostrophes cause filename to be incorrectly reported
From: lewis dot peckover at m-w dot co dot uk
Operating system: all?
PHP version: 5.0.4
PHP Bug Type: Unknown/Other Function
Bug description: File uploads: apostrophes cause filename to be incorrectly
reported
Description:
Any file uploaded that has a name containing an apostrophe ('), eg
foo'bar.txt, will be incorrectly named in the $_FILES array. It will
ignore all characters up to and including the apostrophe.
foo'bar.txt -> bar.txt
Tested on PHP 4.3.10/Apache/FreeBSD 5.3 and PHP 5.0.4/IIS/Windows 2003.
Reproduce code:
---
Expected result:
Array
(
[file] => Array
(
[name] => foo'bar.txt
[type] => text/plain
[tmp_name] => d:\PHP\uploadtemp\php9B1.tmp
[error] => 0
[size] => 9
)
)
Actual result:
--
Array
(
[file] => Array
(
[name] => bar.txt
[type] => text/plain
[tmp_name] => d:\PHP\uploadtemp\php9B1.tmp
[error] => 0
[size] => 9
)
)
--
Edit bug report at http://bugs.php.net/?id=33918&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33918&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33918&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33918&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33918&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33918&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33918&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33918&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33918&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33918&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33918&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33918&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33918&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33918&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33918&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33918&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33918&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33918&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33918&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33918&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33918&r=mysqlcfg
#33917 [Opn->Csd]: number_format incorrect work when use "long" th. separator
ID: 33917 Updated by: [EMAIL PROTECTED] Reported By: shagren at ua dot fm -Status: Open +Status: Closed Bug Type: Strings related Operating System: Win2k/Linux PHP Version: 5.1.0b3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-07-29 14:33:25] shagren at ua dot fm Description: In documentation i can read : Only the first character of thousands_sep is used. For example, if you use foo as thousands_sep on the number 1000, number_format() will return 1f000. But in my example when i use "Long" parameter it ignored and some default value used. I test it on versions 4.3.6, 5.1.0b3 Reproduce code: --- Expected result: 123-456-789 Actual result: -- 123,456,789 -- Edit this bug report at http://bugs.php.net/?id=33917&edit=1
#33917 [NEW]: number_format incorrect work when use "long" th. separator
From: shagren at ua dot fm Operating system: Win2k/Linux PHP version: 5.1.0b3 PHP Bug Type: Strings related Bug description: number_format incorrect work when use "long" th. separator Description: In documentation i can read : Only the first character of thousands_sep is used. For example, if you use foo as thousands_sep on the number 1000, number_format() will return 1f000. But in my example when i use "Long" parameter it ignored and some default value used. I test it on versions 4.3.6, 5.1.0b3 Reproduce code: --- Expected result: 123-456-789 Actual result: -- 123,456,789 -- Edit bug report at http://bugs.php.net/?id=33917&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33917&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33917&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33917&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33917&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33917&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33917&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33917&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33917&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33917&r=support Expected behavior: http://bugs.php.net/fix.php?id=33917&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33917&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33917&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33917&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33917&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33917&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33917&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33917&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33917&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33917&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33917&r=mysqlcfg
#33914 [Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914 User updated by: me at thomaskeller dot biz Reported By: me at thomaskeller dot biz Status: Bogus Bug Type: GD related Operating System: Linux 2.4 shared hosting PHP Version: 4.3.11 New Comment: So, is this a bug in GD and you guys are not responsible or is it me or... a small sentence below the auto responder may have helped. Previous Comments: [2005-07-29 10:47:50] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2005-07-29 02:37:12] me at thomaskeller dot biz Description: Following use case: Uploaded images should be shrinked to a certain size according to our guidelines. Works with jpeg/ png (not palette based) images without a problem, problems arise when used palette based (8bit) images. Resizing via imagecopyresampled/ imagecopyresize works only for images WITHOUT a transparency color set properly. If a transparency color is set in the image, the value of this color is just ignored and a random background color is applied to the "transparent" area. It makes no difference if the image is outputted as gif or 8bit png. If imagecopyresampled/imagecopyresized is called with the same width/height for the source and the target image, the transparency keeps intact. Reproduce code: --- I've setuped a few things on a test server: PHPInfo: http://thomaskeller.biz/work/php/PHP_GIF/info.php Testfile: http://thomaskeller.biz/work/php/PHP_GIF/image.php Testfile (Source): http://thomaskeller.biz/work/php/PHP_GIF/image.phps image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by default, but you can load an own gif file via URL like image.php?filename=http://your.server.com/file.gif The loaded image is per default resized to its double width/ height. -- Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#32107 [Com]: fclose (STDIN|STDOUT|STDERR) not working
ID: 32107 Comment by: Andreas dot Oesterhelt at InTradeSys dot com Reported By: php at the-eend dot org Status: No Feedback Bug Type: CGI related Operating System: Redhat ES3 PHP Version: 4.3.10 New Comment: Here's the test case requested by [EMAIL PROTECTED]: Tested in PHP 4.3.10 (cli) Previous Comments: [2005-03-20 18:01:30] [EMAIL PROTECTED] 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. [2005-02-25 14:09:02] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-02-25 13:33:10] php at the-eend dot org True enough, the resource goes from being a stream to an "Unknown". Unfortunately, my terminal still hangs until the script is complete when I try to log out of the server. If the stream is truly closed (not saying I don't believe you ;)), I guess it must be something else. :( I sense an incoming "bogus"... ;) [2005-02-25 13:03:46] [EMAIL PROTECTED] Why do you think they are not closed? Or use var_dump() in your example: [2005-02-25 12:54:31] php at the-eend dot org Description: This is the same bug as reported and fixed for PHP5 last year: http://bugs.php.net/bug.php?id=27865 , but is still present in 4.3.10. Upgrading to PHP 5 is not an option at this point. Any chance this can be back-ported? With CLI scripts, fclosing STDIN, STDOUT and STDERR have no effect, leaving the sockets open, and the terminal which ran the script hanging. Reproduce code: --- echo STDIN . '|' . STDOUT . '|' . STDERR . "\n"; fclose (STDIN); fclose (STDOUT); fclose (STDERR); echo STDIN . '|' . STDOUT . '|' . STDERR . "\n"; Expected result: The STDIN, STDOUT and STDERR streams should be closed: Resource id #1|Resource id #2|Resource id #3 || (perhaps, though this would mean the value of a 'constant' was being changed...) Actual result: -- The streams are not closed, and remain pointing to the same resources: Resource id #1|Resource id #2|Resource id #3 Resource id #1|Resource id #2|Resource id #3 -- Edit this bug report at http://bugs.php.net/?id=32107&edit=1
#33916 [Opn->Fbk]: Unknown MySQL server host '.'
ID: 33916
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: RH fedora, core 2
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-07-29 12:07:59] deadman_great at mail dot ru
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1
{main} thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=33916&edit=1
#33916 [NEW]: Unknown MySQL server host '.'
From: deadman_great at mail dot ru
Operating system: RH fedora, core 2
PHP version: 5.0.4
PHP Bug Type: PDO related
Bug description: Unknown MySQL server host '.'
Description:
PDO Couldn't connect to MySQL.
Reproduce code:
---
Expected result:
PDO connection.
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000] [2005] Unknown MySQL server host '.' (4)' in
/home/tech/pages/mywatch/pdo.php:3 Stack trace: #0
/home/tech/pages/mywatch/pdo.php(3):
PDO->__construct('mysql:host=loca...', 'root', 'xx...') #1 {main}
thrown in /home/tech/pages/mywatch/pdo.php on line 3
--
Edit bug report at http://bugs.php.net/?id=33916&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33916&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33916&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33916&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33916&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33916&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33916&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33916&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33916&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33916&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33916&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33916&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33916&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33916&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33916&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33916&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33916&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33916&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33916&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33916&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33916&r=mysqlcfg
#33533 [Opn->Csd]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Open +Status: Closed Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez Previous Comments: [2005-07-19 17:27:19] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184 #7 0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299 #8 0x00f03b8b in execute (op_array=0x89aeaec) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87 #9 0x00edd699 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087 #10 0x00e9c995 in php_execute_script (primary_file=0xbfe0f4e0) at /usr/src/apache/php5-200507122030/main/main.c:1672 #11 0x00f48616 in php_handler (r=0x899fbe0) at /usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555 #12 0x0809953a in ap_run_handler (r=0x899fbe0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x899fbe0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x899fbe0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x848) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x848) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=0) at prefork.c:610 #18 0x08097f09 in make_child (s=0x882ea08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbfe0f830, plog=0x8863190, s=0xbfe0f834) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbfe0f9d4) at main.c:618 (gdb) f 3 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 393 S->cols[colno].data = emalloc(colsize+1); (gdb) info locals S = (pdo_odbc_stmt *) 0x8a16794 col = (struct pdo_column_data *) 0x8a12134 dyn = 0 '\0' rc = 0 colnamelen = 7 colsize = 2147483647 [2005-07-18 17:19:36] [EMAIL PROTECTED] Can you do that again, this time type in: bt f 3 info locals thanks! [2005-07-13 01:36:18] scott dot barnett at thuringowa dot qld dot gov dot au Thanks wez, I've got PDO-ODBC working now with snapshot php5-200507122030. If I use PDO this shows up in err_log: FATAL: emalloc(): Unable to allocate -2147483648 bytes FATAL: emalloc(): Unable to allocate -2147483648 bytes FATAL: emalloc(): Unable to allocate -2147483648 bytes If I use the ifx_ functions this shows up in err_log: [Wed Jul 13 09:26:51 2005] [notice] child pid 15980 exit signal Segmentation fault (11) [Wed Jul 13 09:26:51 2005] [notice] child pid 15981 exit signal Segmentation fault (11) Same problems basically, only happens when querying Informix text fie
#33914 [Opn->Bgs]: Resizing palette based images with transparency bit loose transparency
ID: 33914 Updated by: [EMAIL PROTECTED] Reported By: me at thomaskeller dot biz -Status: Open +Status: Bogus Bug Type: GD related Operating System: Linux 2.4 shared hosting PHP Version: 4.3.11 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-07-29 02:37:12] me at thomaskeller dot biz Description: Following use case: Uploaded images should be shrinked to a certain size according to our guidelines. Works with jpeg/ png (not palette based) images without a problem, problems arise when used palette based (8bit) images. Resizing via imagecopyresampled/ imagecopyresize works only for images WITHOUT a transparency color set properly. If a transparency color is set in the image, the value of this color is just ignored and a random background color is applied to the "transparent" area. It makes no difference if the image is outputted as gif or 8bit png. If imagecopyresampled/imagecopyresized is called with the same width/height for the source and the target image, the transparency keeps intact. Reproduce code: --- I've setuped a few things on a test server: PHPInfo: http://thomaskeller.biz/work/php/PHP_GIF/info.php Testfile: http://thomaskeller.biz/work/php/PHP_GIF/image.php Testfile (Source): http://thomaskeller.biz/work/php/PHP_GIF/image.phps image.php loads http://thomaskeller.biz/work/php/PHP_GIF/rose.gif by default, but you can load an own gif file via URL like image.php?filename=http://your.server.com/file.gif The loaded image is per default resized to its double width/ height. -- Edit this bug report at http://bugs.php.net/?id=33914&edit=1
#33910 [Bgs]: Fix of bug #30578 not necessarily correct
ID: 33910 Updated by: [EMAIL PROTECTED] Reported By: jrweir at gmail dot com Status: Bogus Bug Type: Output Control Operating System: all PHP Version: 5.1.0b3 New Comment: Actually this has nothing to do with bug #33772. And the current shutdown order is the right one, it was broken before. Previous Comments: [2005-07-29 01:59:50] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #33772 [2005-07-28 23:07:12] jrweir at gmail dot com Exactly, it had never worked until he requested it to work. That was an example of code that did not work, but does now because the shutdown order was changed (which in turn broke a bunch of people's code that was running under the assumption of a different shutdown order). Before bug #30578: - 0 people had working code that assumed ob flush ran after destruct because it didn't (one guy wanted it to though, so he reported it as a bug - but the bug solution should have been to disallow ob in destructors since they run after the flush in php 5.0) - Many people had code that assumed ob flush ran before destruct After bug #30578: - 0 people have code that assumes ob flush ran after destruct (because it never did before, except for the guy that requested the "bug fix" because he just wanted the behaviour changed for his convienence. The php developer didn't think about the side effects it would cause when they changed the order.) - Many people now have code that doesn't work because they understood the shutdown order and leveraged it to their advantage. It seems to me that when you go stable with 5.1 and the shutdown order is switched, all the people who upgrade from 5.0 that didn't give 5.1b a test are going to be in for a suprise if their code depends on the old shutdown order. [2005-07-28 21:54:58] [EMAIL PROTECTED] >Since calling ob_end*() in a destructor has never worked >nobody has code written expecting it to. This is obviously not true and you know why: see bug #30578. [2005-07-28 19:41:39] jrweir at gmail dot com Currently in 5.1.0b3 the order is 1. call destructors 2. call shutdown functions 3. flush output buffers I think it should be 1. flush output buffers 2. call destructors 3. call shutdown functions Reason: Since calling ob_end*() in a destructor has never worked nobody has code written expecting it to. However, many people (as in bug #33772) have code written expecting destructors to run after output buffering. I'd say there are just as many valid reasons to flush buffers after the destructors run as there are to flush buffers before they run, but since it was the latter way since php 5, why change it? Solution: Make it illegal to do output buffering in a destructor just as it is in an output buffering handler. [2005-07-28 19:13:47] [EMAIL PROTECTED] This is a chicken-and-egg problem that can't be solved in an easy way. Please see bug #33772 for additional details. If you have any ideas what should be the *right* order of calls - please tell your opinion. But remember that we have a lot of different handlers that are called on shutdown. See the current order in php-src/main/main.c, php_request_shutdown() 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 http://bugs.php.net/33910 -- Edit this bug report at http://bugs.php.net/?id=33910&edit=1
#33915 [Opn->Fbk]: Crash in _oci_close_session
ID: 33915
Updated by: [EMAIL PROTECTED]
Reported By: jfbustarret at tf1 dot fr
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-07-29 08:25:19] jfbustarret at tf1 dot fr
Description:
Using php 5.0.4, with the oci8 extension from CVS & the oci_ping code
activated in _oci_open_server, I have random segfaults on my production
servers.
Here is the back trace :
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
2961CALL_OCI_RETURN(OCI(error),
(gdb) bt
#0 0xb78f3779 in _oci_close_session (session=0x8382a20)
at /soft/sources/php/php-5.0.4/ext/oci8/oci8.c:2961
#1 0xb79f0d5e in list_entry_destructor (ptr=0x83590f0)
at /soft/sources/php/php-5.0.4/Zend/zend_list.c:173
#2 0xb79eef48 in zend_hash_apply_deleter (ht=0xb7a72560, p=0x836a4c8)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:618
#3 0xb79ef227 in zend_hash_graceful_reverse_destroy (ht=0xb7a72560)
at /soft/sources/php/php-5.0.4/Zend/zend_hash.c:684
#4 0xb79e144a in shutdown_executor ()
at /soft/sources/php/php-5.0.4/Zend/zend_execute_API.c:284
#5 0xb79e8c86 in zend_deactivate ()
at /soft/sources/php/php-5.0.4/Zend/zend.c:902
#6 0xb79b544c in php_request_shutdown (dummy=0x0)
[...]
(gdb) print *session
$1 = {num = 137800016, persistent = 0 '\0', is_open = 253 'ý',
exclusive = 49 '1', thread = 8 '\b', sessions_list = 0x0, server =
0x0,
pSession = 0x0, pEnv = 0x0, charsetId = 0}
I'll try this patch in _oci_close_session :
if (!session) {
return;
}
+if (!session->server) {
+return;
+}
oci_debug("START _oci_close_session: logging-off
sess=%d",session->num);
Reproduce code:
---
No reproducing code. The crashes are random & time/traffic dependant.
--
Edit this bug report at http://bugs.php.net/?id=33915&edit=1
#33484 [Bgs]: Rendered Text gets Blocks around characters
ID: 33484 User updated by: designshoe at gmx dot net Reported By: designshoe at gmx dot net Status: Bogus Bug Type: GD related Operating System: * PHP Version: 5CVS, 4CVS (2005-06-28) Assigned To: pajoye New Comment: Solution: WORKS FOR ME. > You have a setup problem, sorry. You were right (at least partly). I rendered PNG images with alpha transparency. When I turned that OFF, the font looks just fine, as you said. I will now go on and try to find out whether it is a PNG transparency problem or just my code. Thanks a lot, Thomas Previous Comments: [2005-07-29 08:13:45] [EMAIL PROTECTED] Your configure looks like you use the bundled GD. Be sure you use it and not a random external version. But again, this font works well here, with 4.4, 5.1 (same result as http://krapplack.de/php-bug/textimage_php-4.3.8.png ). You have a setup problem, sorry. --Pierre [2005-07-29 07:56:49] designshoe at gmx dot net Here are the freetype versions: System (1): Freetype 2.1.9 (libfreetype.so.6.3.7), tested with PHP 4.3.8 (worked) and PHP Snapshot (broken). System (2): Freetype 2.x (undeterminable, maybe 2.0.9 according to rpm.pbone.net, libfreetype.so.6.3.0), tested with PHP 4.3.10 and 5.0.3-1.dotdeb.0 (both broken). I will now install Freetype 2.1.10 and the latest Snapshot on system (1) to see what happens. My GD by the way is 2.0.28. Cheers, Thomas [2005-07-28 15:41:17] [EMAIL PROTECTED] Ok, but now please use one of our mailing lists to ask for further information. The font you provided works here, so it does seem to be a bug. [2005-07-28 15:35:59] designshoe at gmx dot net > You see the freetype version in phpinfo(). I thought so too, in the first place. But it only says: FreeType Supportenabled FreeType Linkagewith freetype on system (2). > rpm -q should work even when you are not admin. I do not know if apt works neither other exotic system :) It is a very well secured debian system on which I am not allowed to use "apt-cache search" :) As for now, I have to wait until I get home to check my development system for its version of freetype. Cheers, Thomas [2005-07-28 15:24:31] [EMAIL PROTECTED] You see the freetype version in phpinfo(). rpm -q should work even when you are not admin. I do not know if apt works neither other exotic system :) --Pierre 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/33484 -- Edit this bug report at http://bugs.php.net/?id=33484&edit=1
