Req #53594 [Com]: php-snmp rewrite
Edit report at http://bugs.php.net/bug.php?id=53594edit=1 ID: 53594 Comment by: lytboris at gmail dot com Reported by:lytboris at gmail dot com Summary:php-snmp rewrite Status: Feedback Type: Feature/Change Request Package:SNMP related Operating System: irrelevant PHP Version:5.2.16 Block user comment: N Private report: N New Comment: This patch covers bugs #44193 #45893 #51336 Previous Comments: [2010-12-23 07:20:18] lytboris at gmail dot com I know about version lifecycle. But Cacti 087 (Larry mentioned it) runs on 5.2 branch. Here you are patch for trunk. There is no difference between 5.3 and trunk for now so this patch may be appied to 5.3 branch too. [2010-12-22 22:07:14] paj...@php.net Thanks for this great patch :) However 5.3 is in maintenance mode (and 5.2 is dead btw), please provide a patch against trunk instead. [2010-12-22 20:05:04] lytboris at gmail dot com Patch was created for 5.3 branch and then adopted to be used in 5.2 branch. [2010-12-22 19:49:37] lytboris at gmail dot com Description: The main new feature is multi OID get/getnext/set commands. Another one - strong and simple return value logic: if command fails, return nothing but FALSE. No empty strings, no SNMP error messages as values, etc. Just FALSE. Another effort was to cover source code with unit tests. Results: 100% functions (-zm_info_snmp, but it is not actually snmp function), 94% source code lines. -- Edit this bug report at http://bugs.php.net/bug.php?id=53594edit=1
[PHP-BUG] Bug #53596 [NEW]: Function iconv_mime_decode failed to decode utf-8 header
From:
Operating system: CentOS release 5.5
PHP version: 5.3.4
Package: ICONV related
Bug Type: Bug
Bug description:Function iconv_mime_decode failed to decode utf-8 header
Description:
---
From manual page: http://www.php.net/function.iconv-mime-decode
---
Function iconv_mime_decode can't decode header with non-ascii characters,
if
charset differs from ISO-8859-1.
For example iconv_mime_decode can't decode string
Subject: =?utf-8?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?=
Test script:
---
?php
$plan = array(
// It's erroneous way to encode non-ascii text with ISO-8859-1, but
// in this case the encode and the decode are inverse functions
// i. e. $a == decode(encode($a))
array(
'description'= Non-ASCII characters, ISO-8859-1 to ISO-8859-1
conversion,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello, Bear!),
'prefs' = array(
'input-charset' = 'iso-8859-1',
'output-charset' = 'iso-8859-1',
)
),
// unfortunately fails
array(
'description'= Non-ASCII characters and UTF-8,
'subject'= ÐÑивеÑ, Ðедвед! (Hello, Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and UTF-8,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and Windows-1251
charset,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
),
array(
'description'= Non-ASCII characters and Windows-1251
charset,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
)
);
foreach ($plan as $case) {
printf(\n\nStart: %s\n%s\n, $case['description'], str_repeat(=,
80));
$prefs = $case['prefs'];
$prefs['scheme'] = 'Q';
$subject_encoded = iconv_mime_encode('Subject', $case['subject'],
$prefs);
printf(Encoded subject: %s\n, var_export($subject_encoded, 1));
if (!$subject_encoded) {
$status = 'FAILED due to iconv_mime_encode';
} else {
$status = false === iconv_mime_decode($subject_encoded) ? 'FAILED'
: 'PASSED';
}
printf([%s] %s\n, $status, $case['description']);
}
echo \n;
Expected result:
All tests should pass.
Actual result:
--
Start: Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Encoded subject: 'Subject:
=?iso-8859-1?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,?
=
=?iso-8859-1?Q?=20=D0=9C=D0=B5=D0=B4=D0=B2=D0=B5=D0=B4=D1=8C!=20(Hello,?=
=?iso-8859-1?Q?=20Bear!)?='
[PASSED] Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Start: Non-ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?
=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?='
[FAILED] Non-ASCII characters and UTF-8
Start: Only ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and UTF-8
Start: Only ASCII characters and Windows-1251 charset
Encoded subject: 'Subject: =?windows-1251?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and Windows-1251 charset
Start: Non-ASCII characters and Windows-1251 charset
Encoded subject: 'Subject: =?windows-1251?Q?
=CF=F0=E8=E2=E5=F2,=20=CC=E5=E4=E2=E5=E4=FC!=20(?=
=?windows-1251?Q?Hello,=20Bear!)?='
[FAILED] Non-ASCII characters and Windows-1251 charset
--
Edit bug report at http://bugs.php.net/bug.php?id=53596edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53596r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53596r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53596r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53596r=fixed
Fixed in SVN and need be
[PHP-BUG] Bug #53597 [NEW]: open_basedir not working as documented
From: Operating system: Linux PHP version: 5.3.4 Package: *Directory/Filesystem functions Bug Type: Bug Bug description:open_basedir not working as documented Description: the php manual in the section Description of core php.ini directives (http://www.php.net/manual/en/ini.core.php, checked on 23-dec-10 11:55 utc) states: The restriction specified with open_basedir is actually a prefix, not a directory name. this has been so ever since, but seems now broken at release 5.3.4 - specifying directory name prefix gives access denied errors, only specifying complete directory name seems to work. if the described behaviour is intentional, please fix the documentation *and note the change in BIG BOLD LETTERS in the release announcement*, or, better, fix the php-code to behave as documented. Test script: --- phpmyadmin installed and configured in /u/phpMyAdmin-3.3.8.1-all-languages entry in /usr/lib/php.ini : open_basedir = /tmp/:/u/phpMyAdmin:/usr/lib/php/ according to the documentation, this should give access to the phpmyadmin installation, and used to do so up to php-5.3.3, but now, as of php-5.3.4, gives an error message open_basedir restriction in effect. File(/u/phpMyAdmin-3.3.8.1-all-languages/index.php) is not within the allowed path(s): (/tmp/:/u/phpMyAdmin:/usr/lib/php/) it works when changing /usr/lib/php.ini to open_basedir = /tmp/:/u/phpMyAdmin-3.3.8.1-all-languages:/usr/lib/php/ -- Edit bug report at http://bugs.php.net/bug.php?id=53597edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53597r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53597r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53597r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53597r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53597r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53597r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53597r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53597r=needscript Try newer version: http://bugs.php.net/fix.php?id=53597r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53597r=support Expected behavior: http://bugs.php.net/fix.php?id=53597r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53597r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53597r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53597r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53597r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53597r=dst IIS Stability: http://bugs.php.net/fix.php?id=53597r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53597r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53597r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53597r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53597r=mysqlcfg
[PHP-BUG] Req #53598 [NEW]: GD does not support color profiles
From: Operating system: Irrelevant PHP version: Irrelevant Package: GD related Bug Type: Feature/Change Request Bug description:GD does not support color profiles Description: Hi, It seems that GD currently does not support embedding color profiles into JPEGs created with ImageJpeg(). The colors of the generated JPEG then look different from the ones in the original JPEG if the browser is color-management-capable and the system uses a different profile than was embedded in the original JPEG. For example, I have a large image generated by Adobe Lightroom, which has sRGB embedded as profile. The resized photo generated by GD has lost the profile. I am using Firefox and have a calibrated monitor, so the system does not use sRGB per default. In Firefox the resized picture has different colors then the original one. Only if I force Firefox to use sRGB by setting gfx.color_management.mode to 1, the picture looks the same as the original. But obviously I cannot expect this from my website's visitors. When researching this on the Web I found that many people have that problem but there is no solution in sight. ImageMagick is not an option for me, my hoster does not support it. It would be great if GD could be extended to allow embedding color profiles into images. Thanks, Robert -- Edit bug report at http://bugs.php.net/bug.php?id=53598edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53598r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53598r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53598r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53598r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53598r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53598r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53598r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53598r=needscript Try newer version: http://bugs.php.net/fix.php?id=53598r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53598r=support Expected behavior: http://bugs.php.net/fix.php?id=53598r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53598r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53598r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53598r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53598r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53598r=dst IIS Stability: http://bugs.php.net/fix.php?id=53598r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53598r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53598r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53598r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53598r=mysqlcfg
Bug #50360 [Ver-Csd]: Crash on is_subclass_of() under special conditions (PHP_5_2 only!)
Edit report at http://bugs.php.net/bug.php?id=50360edit=1 ID: 50360 Updated by: il...@php.net Reported by:mjomble at gmail dot com Summary:Crash on is_subclass_of() under special conditions (PHP_5_2 only!) -Status: Verified +Status: Closed Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.2SVN-2009-12-02 (snap) -Assigned To: +Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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. This is fixed in 5.3 Previous Comments: [2009-12-04 22:33:32] fel...@php.net I can reproduce it on 5.2SVN. ==19457== Invalid read of size 4 ==19457==at 0x83BE343: is_a_impl (zend_builtin_functions.c:674) ==19457==by 0x83BE585: zif_is_subclass_of (zend_builtin_functions.c:712) ==19457==by 0x83D5DFF: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==19457==by 0x83DCBA1: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1740) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83D608C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==19457==by 0x83D6F14: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83AC175: zend_execute_scripts (zend.c:1134) ==19457==by 0x8343300: php_execute_script (main.c:2035) ==19457==by 0x8436388: main (php_cli.c:1162) ==19457== Address 0x45e79f8 is 184 bytes inside a block of size 256 free'd ==19457==at 0x4023E8C: realloc (vg_replace_malloc.c:429) ==19457==by 0x8385ABD: _erealloc (zend_alloc.c:2319) ==19457==by 0x83D685E: zend_ptr_stack_2_push (zend_ptr_stack.h:73) ==19457==by 0x83D5A86: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:148) ==19457==by 0x83DCBA1: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1740) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x839C576: zend_call_function (zend_execute_API.c:1038) ==19457==by 0x83C6139: zend_call_method (zend_interfaces.c:88) ==19457==by 0x821D2AC: zif_spl_autoload_call (php_spl.c:382) ==19457==by 0x839C7C9: zend_call_function (zend_execute_API.c:1052) ==19457==by 0x839D0B9: zend_lookup_class_ex (zend_execute_API.c:1145) ==19457==by 0x839E2E4: zend_fetch_class (zend_execute_API.c:1560) ==19457==by 0x83D8A70: ZEND_FETCH_CLASS_SPEC_CONST_HANDLER (zend_vm_execute.h:650) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83E4B14: ZEND_INCLUDE_OR_EVAL_SPEC_TMP_HANDLER (zend_vm_execute.h:4681) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x839C576: zend_call_function (zend_execute_API.c:1038) ==19457==by 0x83C6139: zend_call_method (zend_interfaces.c:88) ==19457==by 0x821D2AC: zif_spl_autoload_call (php_spl.c:382) ==19457==by 0x839C7C9: zend_call_function (zend_execute_API.c:1052) ==19457==by 0x839D0B9: zend_lookup_class_ex (zend_execute_API.c:1145) ==19457==by 0x839D3BA: zend_lookup_class (zend_execute_API.c:1177) ==19457==by 0x83BE2DE: is_a_impl (zend_builtin_functions.c:662) ==19457==by 0x83BE585: zif_is_subclass_of (zend_builtin_functions.c:712) ==19457==by 0x83D5DFF: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==19457==by 0x83DCBA1: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1740) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83D608C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==19457==by 0x83D6F14: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457== ==19457== Invalid read of size 4 ==19457==at 0x83BE374: is_a_impl (zend_builtin_functions.c:678) ==19457==by 0x83BE585: zif_is_subclass_of (zend_builtin_functions.c:712) ==19457==by 0x83D5DFF: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:200) ==19457==by 0x83DCBA1: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1740) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83D608C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==19457==by 0x83D6F14: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322) ==19457==by 0x83D5887: execute (zend_vm_execute.h:92) ==19457==by 0x83AC175: zend_execute_scripts (zend.c:1134) ==19457==by 0x8343300: php_execute_script (main.c:2035) ==19457==by 0x8436388: main (php_cli.c:1162) ==19457== Address 0x45e79fc is 188 bytes inside a block of size 256 free'd
Req #53598 [Opn-Asn]: GD does not support color profiles
Edit report at http://bugs.php.net/bug.php?id=53598edit=1 ID: 53598 Updated by: paj...@php.net Reported by:the-ninth at gmx dot com Summary:GD does not support color profiles -Status: Open +Status: Assigned Type: Feature/Change Request Package:GD related Operating System: Irrelevant PHP Version:Irrelevant -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N New Comment: hi, Can you send me a couple of images with the profile(s) you are referring to please? Previous Comments: [2010-12-23 12:49:13] the-ninth at gmx dot com Description: Hi, It seems that GD currently does not support embedding color profiles into JPEGs created with ImageJpeg(). The colors of the generated JPEG then look different from the ones in the original JPEG if the browser is color-management-capable and the system uses a different profile than was embedded in the original JPEG. For example, I have a large image generated by Adobe Lightroom, which has sRGB embedded as profile. The resized photo generated by GD has lost the profile. I am using Firefox and have a calibrated monitor, so the system does not use sRGB per default. In Firefox the resized picture has different colors then the original one. Only if I force Firefox to use sRGB by setting gfx.color_management.mode to 1, the picture looks the same as the original. But obviously I cannot expect this from my website's visitors. When researching this on the Web I found that many people have that problem but there is no solution in sight. ImageMagick is not an option for me, my hoster does not support it. It would be great if GD could be extended to allow embedding color profiles into images. Thanks, Robert -- Edit this bug report at http://bugs.php.net/bug.php?id=53598edit=1
Req #53598 [Asn]: GD does not support color profiles
Edit report at http://bugs.php.net/bug.php?id=53598edit=1 ID: 53598 User updated by:the-ninth at gmx dot com Reported by:the-ninth at gmx dot com Summary:GD does not support color profiles Status: Assigned Type: Feature/Change Request Package:GD related Operating System: Irrelevant PHP Version:Irrelevant Assigned To:pajoye Block user comment: N Private report: N New Comment: Hi, Check these two pictures: http://www.the-ninth.com/demo/demo_php.jpg http://www.the-ninth.com/demo/demo_lightroom.jpg demo_lightroom.jpg was generated by Adobe Lightroom and contains the profile. Demo.php was generated by GD and does not contain the profile. To see the difference you need to have a system color profile that is different from sRGB, like you would have with a calibrated monitor. Then if you open them in Firefox you'll see the difference. I think Safari does color management too, so you might see the difference there as well. Maybe also IE9. If you do not have a calibrated monitor, then probably sRGB is the system default anyway, so in this case Firefox takes sRGB for the picture without the profile and the result is correct. Thanks, Robert Previous Comments: [2010-12-23 15:37:47] paj...@php.net hi, Can you send me a couple of images with the profile(s) you are referring to please? [2010-12-23 12:49:13] the-ninth at gmx dot com Description: Hi, It seems that GD currently does not support embedding color profiles into JPEGs created with ImageJpeg(). The colors of the generated JPEG then look different from the ones in the original JPEG if the browser is color-management-capable and the system uses a different profile than was embedded in the original JPEG. For example, I have a large image generated by Adobe Lightroom, which has sRGB embedded as profile. The resized photo generated by GD has lost the profile. I am using Firefox and have a calibrated monitor, so the system does not use sRGB per default. In Firefox the resized picture has different colors then the original one. Only if I force Firefox to use sRGB by setting gfx.color_management.mode to 1, the picture looks the same as the original. But obviously I cannot expect this from my website's visitors. When researching this on the Web I found that many people have that problem but there is no solution in sight. ImageMagick is not an option for me, my hoster does not support it. It would be great if GD could be extended to allow embedding color profiles into images. Thanks, Robert -- Edit this bug report at http://bugs.php.net/bug.php?id=53598edit=1
Req #53598 [Asn]: GD does not support color profiles
Edit report at http://bugs.php.net/bug.php?id=53598edit=1 ID: 53598 Updated by: paj...@php.net Reported by:the-ninth at gmx dot com Summary:GD does not support color profiles Status: Assigned Type: Feature/Change Request Package:GD related Operating System: Irrelevant PHP Version:Irrelevant Assigned To:pajoye Block user comment: N Private report: N New Comment: I think I need more visible differences as I don't have a calibration system in place nor a calibrated monitor :P I will already analyze the delta in the meta information of both images. Previous Comments: [2010-12-23 15:45:06] the-ninth at gmx dot com Hi, Check these two pictures: http://www.the-ninth.com/demo/demo_php.jpg http://www.the-ninth.com/demo/demo_lightroom.jpg demo_lightroom.jpg was generated by Adobe Lightroom and contains the profile. Demo.php was generated by GD and does not contain the profile. To see the difference you need to have a system color profile that is different from sRGB, like you would have with a calibrated monitor. Then if you open them in Firefox you'll see the difference. I think Safari does color management too, so you might see the difference there as well. Maybe also IE9. If you do not have a calibrated monitor, then probably sRGB is the system default anyway, so in this case Firefox takes sRGB for the picture without the profile and the result is correct. Thanks, Robert [2010-12-23 15:37:47] paj...@php.net hi, Can you send me a couple of images with the profile(s) you are referring to please? [2010-12-23 12:49:13] the-ninth at gmx dot com Description: Hi, It seems that GD currently does not support embedding color profiles into JPEGs created with ImageJpeg(). The colors of the generated JPEG then look different from the ones in the original JPEG if the browser is color-management-capable and the system uses a different profile than was embedded in the original JPEG. For example, I have a large image generated by Adobe Lightroom, which has sRGB embedded as profile. The resized photo generated by GD has lost the profile. I am using Firefox and have a calibrated monitor, so the system does not use sRGB per default. In Firefox the resized picture has different colors then the original one. Only if I force Firefox to use sRGB by setting gfx.color_management.mode to 1, the picture looks the same as the original. But obviously I cannot expect this from my website's visitors. When researching this on the Web I found that many people have that problem but there is no solution in sight. ImageMagick is not an option for me, my hoster does not support it. It would be great if GD could be extended to allow embedding color profiles into images. Thanks, Robert -- Edit this bug report at http://bugs.php.net/bug.php?id=53598edit=1
[PHP-BUG] Req #53600 [NEW]: Localised namespace importing within codeblocks
From:
Operating system:
PHP version: 5.3.4
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Localised namespace importing within codeblocks
Description:
It would be nice to important an entire namespace into global space, but
only for
a controlled section of code
Test script:
---
/* desktop.php */
?php
namespace desktop;
class Window{...}
class Icon{...}
class Button{...}
?
/* index.php */
?php
require 'desktop.php';
global_function();
{
use desktop;
$window1=new Window();
$window2=new Window();
$button1=new Button();
}
more_global_functions();
?
Expected result:
Whilst in the codeblock the namespace is available as if it were global,
but once
outside it is no longer globally available. The global namespace should be
unaffected afterwards
Actual result:
--
currently namespaces cannot be imported entirely under the justification
that it
will pollute the global namespace. I believe that if only done for
controlled
regions of code this can be avoided code can be more cleanly written
--
Edit bug report at http://bugs.php.net/bug.php?id=53600edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53600r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53600r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53600r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53600r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53600r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53600r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53600r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53600r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53600r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53600r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53600r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53600r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53600r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53600r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53600r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53600r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53600r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53600r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53600r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53600r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53600r=mysqlcfg
Bug #53596 [Opn-Csd]: Function iconv_mime_decode failed to decode utf-8 header
Edit report at http://bugs.php.net/bug.php?id=53596edit=1
ID: 53596
User updated by:anton dot a dot minin at gmail dot com
Reported by:anton dot a dot minin at gmail dot com
Summary:Function iconv_mime_decode failed to decode utf-8
header
-Status: Open
+Status: Closed
Type: Bug
Package:ICONV related
Operating System: CentOS release 5.5
PHP Version:5.3.4
Block user comment: N
Private report: N
New Comment:
With the php.ini option iconv.internal_encoding=utf-8 it works properly.
Previous Comments:
[2010-12-23 11:02:27] anton dot a dot minin at gmail dot com
Description:
---
From manual page: http://www.php.net/function.iconv-mime-decode
---
Function iconv_mime_decode can't decode header with non-ascii
characters, if
charset differs from ISO-8859-1.
For example iconv_mime_decode can't decode string
Subject:
=?utf-8?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?=
Test script:
---
?php
$plan = array(
// It's erroneous way to encode non-ascii text with ISO-8859-1, but
// in this case the encode and the decode are inverse functions
// i. e. $a == decode(encode($a))
array(
'description'= Non-ASCII characters, ISO-8859-1 to
ISO-8859-1 conversion,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'iso-8859-1',
'output-charset' = 'iso-8859-1',
)
),
// unfortunately fails
array(
'description'= Non-ASCII characters and UTF-8,
'subject'= ÐÑивеÑ, Ðедвед! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and UTF-8,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and Windows-1251
charset,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
),
array(
'description'= Non-ASCII characters and Windows-1251
charset,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
)
);
foreach ($plan as $case) {
printf(\n\nStart: %s\n%s\n, $case['description'], str_repeat(=,
80));
$prefs = $case['prefs'];
$prefs['scheme'] = 'Q';
$subject_encoded = iconv_mime_encode('Subject', $case['subject'],
$prefs);
printf(Encoded subject: %s\n, var_export($subject_encoded, 1));
if (!$subject_encoded) {
$status = 'FAILED due to iconv_mime_encode';
} else {
$status = false === iconv_mime_decode($subject_encoded) ?
'FAILED' : 'PASSED';
}
printf([%s] %s\n, $status, $case['description']);
}
echo \n;
Expected result:
All tests should pass.
Actual result:
--
Start: Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Encoded subject: 'Subject:
=?iso-8859-1?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,?
=
=?iso-8859-1?Q?=20=D0=9C=D0=B5=D0=B4=D0=B2=D0=B5=D0=B4=D1=8C!=20(Hello,?=
=?iso-8859-1?Q?=20Bear!)?='
[PASSED] Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Start: Non-ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?
=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?='
[FAILED] Non-ASCII characters and UTF-8
Start: Only ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and UTF-8
Start: Only ASCII characters and Windows-1251 charset
Encoded subject: 'Subject: =?windows-1251?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and Windows-1251 charset
Start: Non-ASCII characters and Windows-1251 charset
Encoded subject: 'Subject: =?windows-1251?Q?
Bug #53596 [Csd-Bgs]: Function iconv_mime_decode failed to decode utf-8 header
Edit report at http://bugs.php.net/bug.php?id=53596edit=1
ID: 53596
Updated by: cataphr...@php.net
Reported by:anton dot a dot minin at gmail dot com
Summary:Function iconv_mime_decode failed to decode utf-8
header
-Status: Closed
+Status: Bogus
Type: Bug
Package:ICONV related
Operating System: CentOS release 5.5
PHP Version:5.3.4
Block user comment: N
Private report: N
Previous Comments:
[2010-12-23 20:18:03] anton dot a dot minin at gmail dot com
With the php.ini option iconv.internal_encoding=utf-8 it works properly.
[2010-12-23 11:02:27] anton dot a dot minin at gmail dot com
Description:
---
From manual page: http://www.php.net/function.iconv-mime-decode
---
Function iconv_mime_decode can't decode header with non-ascii
characters, if
charset differs from ISO-8859-1.
For example iconv_mime_decode can't decode string
Subject:
=?utf-8?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?=
Test script:
---
?php
$plan = array(
// It's erroneous way to encode non-ascii text with ISO-8859-1, but
// in this case the encode and the decode are inverse functions
// i. e. $a == decode(encode($a))
array(
'description'= Non-ASCII characters, ISO-8859-1 to
ISO-8859-1 conversion,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'iso-8859-1',
'output-charset' = 'iso-8859-1',
)
),
// unfortunately fails
array(
'description'= Non-ASCII characters and UTF-8,
'subject'= ÐÑивеÑ, Ðедвед! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and UTF-8,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
)
),
array(
'description'= Only ASCII characters and Windows-1251
charset,
'subject'= Hello, Bear!,
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
),
array(
'description'= Non-ASCII characters and Windows-1251
charset,
'subject'= ÐÑивеÑ, ÐедведÑ! (Hello,
Bear!),
'prefs' = array(
'input-charset' = 'utf-8',
'output-charset' = 'windows-1251',
)
)
);
foreach ($plan as $case) {
printf(\n\nStart: %s\n%s\n, $case['description'], str_repeat(=,
80));
$prefs = $case['prefs'];
$prefs['scheme'] = 'Q';
$subject_encoded = iconv_mime_encode('Subject', $case['subject'],
$prefs);
printf(Encoded subject: %s\n, var_export($subject_encoded, 1));
if (!$subject_encoded) {
$status = 'FAILED due to iconv_mime_encode';
} else {
$status = false === iconv_mime_decode($subject_encoded) ?
'FAILED' : 'PASSED';
}
printf([%s] %s\n, $status, $case['description']);
}
echo \n;
Expected result:
All tests should pass.
Actual result:
--
Start: Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Encoded subject: 'Subject:
=?iso-8859-1?Q?=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,?
=
=?iso-8859-1?Q?=20=D0=9C=D0=B5=D0=B4=D0=B2=D0=B5=D0=B4=D1=8C!=20(Hello,?=
=?iso-8859-1?Q?=20Bear!)?='
[PASSED] Non-ASCII characters, ISO-8859-1 to ISO-8859-1 conversion
Start: Non-ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?
=D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82,=20=D0=9C=D0=B5?=
=?utf-8?Q?=D0=B4=D0=B2=D0=B5=D0=B4!=20(Hello,=20Bear!)?='
[FAILED] Non-ASCII characters and UTF-8
Start: Only ASCII characters and UTF-8
Encoded subject: 'Subject: =?utf-8?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and UTF-8
Start: Only ASCII characters and Windows-1251 charset
Encoded subject: 'Subject: =?windows-1251?Q?Hello,=20Bear!?='
[PASSED] Only ASCII characters and Windows-1251 charset
Start: Non-ASCII characters and Windows-1251 charset
[PHP-BUG] Bug #53601 [NEW]: function rename
From:
Operating system: debian lenny
PHP version: 5.2.16
Package: Unknown/Other Function
Bug Type: Bug
Bug description:function rename
Description:
---
From manual page: http://www.php.net/function.rename
---
This function should return false on error during file renomination, but in
my test script inclusion is executed but renomination it's not executed (no
output, expected output:0).
Test script:
---
$file = getcwd()./test.php;
$file2 = $file..inc;
if (file_exists($file))
{ include $file;
echo rename($file,$file2);
}
--
Edit bug report at http://bugs.php.net/bug.php?id=53601edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53601r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53601r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53601r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53601r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53601r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53601r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53601r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53601r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53601r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53601r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53601r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53601r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53601r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53601r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53601r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53601r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53601r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53601r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53601r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53601r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53601r=mysqlcfg
Req #53598 [Asn]: GD does not support color profiles
Edit report at http://bugs.php.net/bug.php?id=53598edit=1 ID: 53598 User updated by:the-ninth at gmx dot com Reported by:the-ninth at gmx dot com Summary:GD does not support color profiles Status: Assigned Type: Feature/Change Request Package:GD related Operating System: Irrelevant PHP Version:Irrelevant Assigned To:pajoye Block user comment: N Private report: N New Comment: Hi, Try this one: http://www.the-ninth.com/demo/demo_php_argb.jpg http://www.the-ninth.com/demo/demo_lightroom_argb.jpg It was generated in AdobeRGB color space and the profile was removed during resizing. I assume that your Firefox should display it differently, because for the one from Lightroom it knows that it is AdobeRGB while for the one from PHP/GD it will fall back to sRGB. But in any case, the essence is that color profiles are a part of images and at least some current browsers rely on this information. At the moment it is FF and Safari, and IE9 will have color-management too. Then the problem will affect the majority of users. So for the future it would be really helpful if GD would allow to read/write color profiles. Cheers, Robert Previous Comments: [2010-12-23 15:52:56] paj...@php.net I think I need more visible differences as I don't have a calibration system in place nor a calibrated monitor :P I will already analyze the delta in the meta information of both images. [2010-12-23 15:45:06] the-ninth at gmx dot com Hi, Check these two pictures: http://www.the-ninth.com/demo/demo_php.jpg http://www.the-ninth.com/demo/demo_lightroom.jpg demo_lightroom.jpg was generated by Adobe Lightroom and contains the profile. Demo.php was generated by GD and does not contain the profile. To see the difference you need to have a system color profile that is different from sRGB, like you would have with a calibrated monitor. Then if you open them in Firefox you'll see the difference. I think Safari does color management too, so you might see the difference there as well. Maybe also IE9. If you do not have a calibrated monitor, then probably sRGB is the system default anyway, so in this case Firefox takes sRGB for the picture without the profile and the result is correct. Thanks, Robert [2010-12-23 15:37:47] paj...@php.net hi, Can you send me a couple of images with the profile(s) you are referring to please? [2010-12-23 12:49:13] the-ninth at gmx dot com Description: Hi, It seems that GD currently does not support embedding color profiles into JPEGs created with ImageJpeg(). The colors of the generated JPEG then look different from the ones in the original JPEG if the browser is color-management-capable and the system uses a different profile than was embedded in the original JPEG. For example, I have a large image generated by Adobe Lightroom, which has sRGB embedded as profile. The resized photo generated by GD has lost the profile. I am using Firefox and have a calibrated monitor, so the system does not use sRGB per default. In Firefox the resized picture has different colors then the original one. Only if I force Firefox to use sRGB by setting gfx.color_management.mode to 1, the picture looks the same as the original. But obviously I cannot expect this from my website's visitors. When researching this on the Web I found that many people have that problem but there is no solution in sight. ImageMagick is not an option for me, my hoster does not support it. It would be great if GD could be extended to allow embedding color profiles into images. Thanks, Robert -- Edit this bug report at http://bugs.php.net/bug.php?id=53598edit=1
Bug #53597 [Opn-Dup]: open_basedir not working as documented
Edit report at http://bugs.php.net/bug.php?id=53597edit=1 ID: 53597 Updated by: ahar...@php.net Reported by:hsk at fli-leibniz dot de Summary:open_basedir not working as documented -Status: Open +Status: Duplicate Type: Bug -Package:*Directory/Filesystem functions +Package:Safe Mode/open_basedir Operating System: Linux PHP Version:5.3.4 Block user comment: N Private report: N New Comment: Duplicate of bug #53577. Previous Comments: [2010-12-23 12:38:27] hsk at fli-leibniz dot de Description: the php manual in the section Description of core php.ini directives (http://www.php.net/manual/en/ini.core.php, checked on 23-dec-10 11:55 utc) states: The restriction specified with open_basedir is actually a prefix, not a directory name. this has been so ever since, but seems now broken at release 5.3.4 - specifying directory name prefix gives access denied errors, only specifying complete directory name seems to work. if the described behaviour is intentional, please fix the documentation *and note the change in BIG BOLD LETTERS in the release announcement*, or, better, fix the php-code to behave as documented. Test script: --- phpmyadmin installed and configured in /u/phpMyAdmin-3.3.8.1-all-languages entry in /usr/lib/php.ini : open_basedir = /tmp/:/u/phpMyAdmin:/usr/lib/php/ according to the documentation, this should give access to the phpmyadmin installation, and used to do so up to php-5.3.3, but now, as of php-5.3.4, gives an error message open_basedir restriction in effect. File(/u/phpMyAdmin-3.3.8.1-all-languages/index.php) is not within the allowed path(s): (/tmp/:/u/phpMyAdmin:/usr/lib/php/) it works when changing /usr/lib/php.ini to open_basedir = /tmp/:/u/phpMyAdmin-3.3.8.1-all-languages:/usr/lib/php/ -- Edit this bug report at http://bugs.php.net/bug.php?id=53597edit=1
Bug #53601 [Opn-Fbk]: function rename
Edit report at http://bugs.php.net/bug.php?id=53601edit=1
ID: 53601
Updated by: ahar...@php.net
Reported by:tom_84 at hotmail dot it
Summary:function rename
-Status: Open
+Status: Feedback
Type: Bug
-Package:Unknown/Other Function
+Package:Filesystem function related
Operating System: debian lenny
PHP Version:5.2.16
Block user comment: N
Private report: N
New Comment:
Why are you expecting rename() to fail in this case?
Even if $file was open when rename() was called (and it's not, in this
case), that doesn't prevent a file being renamed on most operating
systems, Linux included.
Previous Comments:
[2010-12-24 00:32:36] tom_84 at hotmail dot it
Description:
---
From manual page: http://www.php.net/function.rename
---
This function should return false on error during file renomination, but
in my test script inclusion is executed but renomination it's not
executed (no output, expected output:0).
Test script:
---
$file = getcwd()./test.php;
$file2 = $file..inc;
if (file_exists($file))
{ include $file;
echo rename($file,$file2);
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=53601edit=1
