[PHP-BUG] Req #54502 [NEW]: Add support for the "BITS" datatype
From:
Operating system:
PHP version: trunk-SVN-2011-04-10 (SVN)
Package: SNMP related
Bug Type: Feature/Change Request
Bug description:Add support for the "BITS" datatype
Description:
The SNMP command line tools are able to translate the numeric return values
for OIDs of the "BITS" datatype back to meaningful string values by parsing
the relevant parts of the MIB. The PHP functions currently seem unable to
do that.
I.e. in the following example I would like to get the string "notification"
or "set" as return value but only get "0" or "1". As there is no other
method to find and parse the MIB I'm left with hardcoding the values in the
PHP script:
$ snmptranslate -Td DISMAN-EVENT-MIB::mteEventActions
DISMAN-EVENT-MIB::mteEventActions
mteEventActions OBJECT-TYPE
-- FROM DISMAN-EVENT-MIB
SYNTAXBITS {notification(0), set(1)}
Test script:
---
>From commandline (mind the strange quotes, they're neccessary!):
$ snmpwalk -v2c -c private localhost
"DISMAN-EVENT-MIB::mteEventActions.\"_snmpd\".'_linkDown'"
DISMAN-EVENT-MIB::mteEventActions."_snmpd".'_linkDown' = BITS: 80
notification(0)
With PHP:
snmp_set_valueretrieval(SNMP_VALUE_OBJECT);
$snmp = new SNMP(SNMP_VERSION_2C, 'localhost', 'private');
$x =
$snmp->get("DISMAN-EVENT-MIB::mteEventActions.\"_snmpd\".'_linkDown'");
var_dump($x);
var_dump(bin2hex($x->value));
I get:
object(stdClass)#190 (2) {
["type"]=> int(4)
["value"]=> string(1) "�"
}
string(2) "80"
The value is not even numerical, it has to be converted to 0x80 using
bin2hex()!
Expected result:
Maybe
* the SNMP_VALUE_OBJECT representation object can be enhanced to include
alternative representations:
object(stdClass)#190 (2) {
["type"]=> int(4)
["value"]=> string(1) "�"
["bits_value"]=> string(15) "notification(0)"
}
* or the the snmp_set_enum_print() function is used to toggle BITS, too
* or a snmp_set_bits_print() function is introduced
* or a snmp_translate() function is introduced that returns the
"snmptranslate" output as PHP data structure
--
Edit bug report at http://bugs.php.net/bug.php?id=54502&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54502&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54502&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54502&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54502&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54502&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54502&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54502&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54502&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54502&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54502&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54502&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54502&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54502&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54502&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54502&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54502&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54502&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54502&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54502&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54502&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54502&r=mysqlcfg
Bug #38120 [Com]: display_errors set to Off while Status is on
Edit report at http://bugs.php.net/bug.php?id=38120&edit=1 ID: 38120 Comment by: danielle dot davout at gmail dot com Reported by:jms82882 at yahoo dot com Summary:display_errors set to Off while Status is on Status: Bogus Type: Bug Package:*Configuration Issues Operating System: Windows XP PHP Version:5.1.4 Block user comment: N Private report: N New Comment: for me phpinfo() states display_errors =Off and it is not true ! TPC! System Overview a plugin of wordpress confirms : The display_errors setting in php.ini is set to ON. This means that PHP errors, and warnings are being displayed. Such warnings can cause sensitive information to be revealed to users (paths, database queries, etc.). they are not looking at the same php.ini .. I know the one that phpinfo says it is looking at : PHP Version 5.2.6-1+lenny9 System Linux spihost1 2.6.32-xenU-3831-x86_64 #12 SMP Tue Oct 12 18:07:01 CEST 2010 x86_64 Build Date Aug 4 2010 05:59:12 Server API CGI/FastCGI Virtual Directory Support disabled Configuration File (php.ini) Path /etc/php5/cgi I can see it and even editing it (without being able to change php's behaviour regarding the display of errors once I have changed to On ...) disable_functions no valueno value display_errors Off Off display_startup_errors Off Off I wish I knew the one that TPC! System Overview is looking at it would seemed more accurate ! (if it existed) Previous Comments: [2006-07-17 13:32:33] jms82882 at yahoo dot com then would you kindly specify which php.ini I am to edit please Thank you [2006-07-17 06:36:57] tony2...@php.net You're editing wrong php.ini. [2006-07-17 01:30:45] jms82882 at yahoo dot com Description: Web Server Apache 2.0.58 PHP installed on July 16 2006 PHP Ver. 5.1.4 OS WinXP P4 1.7GHZ/512MB using stadard php.ini not php.ini-dist Modified php.ini setting display_errors to = Off Current status of display_errors = On Saved, Rebooted phpinfo() still states display_errers =On Reproduce code: --- http://mail.secompservices.com/phpdiag.php Expected result: show phpinfo() and link to curr. php.ini Actual result: -- phpinfo states that display_errors = On while php.ini stares it should be off -- Edit this bug report at http://bugs.php.net/bug.php?id=38120&edit=1
Bug #54479 [Com]: round(1e15+0.1) returns 1e15+0.1 instead of 1e15
Edit report at http://bugs.php.net/bug.php?id=54479&edit=1
ID: 54479
Comment by: uncorrelated at yahoo dot co dot jp
Reported by:for-bugs at hnw dot jp
Summary:round(1e15+0.1) returns 1e15+0.1 instead of 1e15
Status: Bogus
Type: Bug
Package:Math related
Operating System: any
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I'm suprized that floating point numbers of PHP doesn't support for IEEE
754. I'd like to confirm wheather PHP 5.3 supports for IEEE 754 or not.
IEEE 754 ensures that 1000 differs from 1000.125
(see appendix). Then, IEEE 754 requires round(1000.125)
returns 1000. In fact, the function of PHP 5.2.17 returns
1000.
In spite of that, the function of PHP 5.3.6 returns
1000.125. It seems to be strange. If it is NOT a bug, PHP
5.3 doesn't support IEEE 754.
Mr hnw may think that PHP should support for IEEE 754 as long as the
system allows it, and the cutoff (precious) value shouldn't affect any
operation but printing.
Appendix:
(Decimal)1000.125 is represented as the followings:
Bits of Sign: 0
Bits of Exponent: 111
Bits of Significand:
11000110101101010010011000110101
(Decimal)1000 is represented as the followings:
Bits of Sign: 0
Bits of Exponent: 111
Bits of Significand:
11000110101101010010011000110100
The significand of 1000.125 isn't same as that of
1000 (See the right edges of them).
Previous Comments:
[2011-04-07 14:19:06] cataphr...@php.net
If anything, the cutoff value is too high:
The accuracy (effective number of digits to the right of the decimal
point) of a double is given by 15.9546-log10(|x|) and:
In[22]:= Solve[$MachinePrecision-Log[10, Abs[x]]==1.,x]
14
Out[22]= {{x -> 9.0072 10 }}
[2011-04-07 01:52:10] for-bugs at hnw dot jp
My test script seems to be wrong. How about next one?
= 1e15) {
return value;
}
[2011-04-06 19:39:39] der...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
.
[2011-04-06 19:22:45] for-bugs at hnw dot jp
Description:
When round() is called with 1 argument which value is between 1e15 and
2^53, round() returns non-rounded value even if the value has fractional
part.
For instance, though 1e15 is exact number as IEEE 754 double precision,
round(1e15+0.1) returns 1e15+0.1. I think 1e15 is better result.
Test script:
---
http://bugs.php.net/bug.php?id=54479&edit=1
Bug #37738 [Wfx->Opn]: basename does not work with Japanese
Edit report at http://bugs.php.net/bug.php?id=37738&edit=1
ID: 37738
Updated by: c...@php.net
Reported by:joey at alegria dot co dot jp
Summary:basename does not work with Japanese
-Status: Wont fix
+Status: Open
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Fedora Core 4
PHP Version:5CVS-2006-06-08 (CVS)
Block user comment: N
Private report: N
New Comment:
I am reopening this as PHP 6 is not developed any more and the bug is
still valid.
Previous Comments:
[2006-06-08 06:37:11] der...@php.net
Won't fix in PHP 5. This will be implemented for PHP 6.
[2006-06-08 06:09:54] joey at alegria dot co dot jp
Description:
Simply put, basename() does ot work with Japanese filepaths. If the
filename is Japanese only the extension part of the filename is
returned. So a filename "/folder/t@C¼.txt" resolves to just
".txt". I discovered the problem when performing a basename() on the
$_FILES array's 'name' element for uploaded Japanese files, however
after testing the bug occurs no matter how you supply the filename.
My PHP environment is running with UTF-8 internal encoding.
The code snippet below illustrates this perfectly.
Reproduce code:
---
Expected result:
The full filename of the romanized file is
/myfolder/roman_filename.txt.
The basename of the romanized file is roman_filename.txt.
The full filename of the Japanese file is
/myfolder/ú{êÌt@C¼.txt.
The basename of the Japanese file is ú{êÌt@C¼.txt.
Actual result:
--
The full filename of the romanized file is
/myfolder/roman_filename.txt.
The basename of the romanized file is roman_filename.txt.
The full filename of the Japanese file is
/myfolder/ú{êÌt@C¼.txt.
The basename of the Japanese file is .txt.
--
Edit this bug report at http://bugs.php.net/bug.php?id=37738&edit=1
Bug #38120 [Com]: display_errors set to Off while Status is on
Edit report at http://bugs.php.net/bug.php?id=38120&edit=1
ID: 38120
Comment by: danielle dot davout at gmail dot com
Reported by:jms82882 at yahoo dot com
Summary:display_errors set to Off while Status is on
Status: Bogus
Type: Bug
Package:*Configuration Issues
Operating System: Windows XP
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
My mistake ! sorry..
I forgot I have also changed my /etc/wordpress/wp-config.php
that overrides WP_DEBUG !
define('WP_DEBUG', false); did the "trick"
Previous Comments:
[2011-04-10 15:52:53] danielle dot davout at gmail dot com
for me
phpinfo() states display_errors =Off
and it is not true !
TPC! System Overview a plugin of wordpress confirms :
The display_errors setting in php.ini is set to ON. This means that PHP
errors, and warnings are being displayed. Such warnings can cause
sensitive information to be revealed to users (paths, database queries,
etc.).
they are not looking at the same php.ini ..
I know the one that phpinfo says it is looking at :
PHP Version 5.2.6-1+lenny9
System Linux spihost1 2.6.32-xenU-3831-x86_64 #12 SMP Tue Oct 12
18:07:01 CEST 2010 x86_64
Build Date Aug 4 2010 05:59:12
Server API CGI/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /etc/php5/cgi
I can see it and even editing it (without being able to change php's
behaviour regarding the display of errors once I have changed to On ...)
disable_functions no valueno value
display_errors Off Off
display_startup_errors Off Off
I wish I knew the one that TPC! System Overview is looking at it
would seemed more accurate ! (if it existed)
[2006-07-17 13:32:33] jms82882 at yahoo dot com
then would you kindly specify which php.ini I am to edit please
Thank you
[2006-07-17 06:36:57] tony2...@php.net
You're editing wrong php.ini.
[2006-07-17 01:30:45] jms82882 at yahoo dot com
Description:
Web Server Apache 2.0.58
PHP installed on July 16 2006
PHP Ver. 5.1.4
OS WinXP P4 1.7GHZ/512MB
using stadard php.ini not php.ini-dist
Modified php.ini setting display_errors to = Off
Current status of display_errors = On
Saved, Rebooted phpinfo() still states display_errers =On
Reproduce code:
---
http://mail.secompservices.com/phpdiag.php
Expected result:
show phpinfo()
and link to curr. php.ini
Actual result:
--
phpinfo states that display_errors = On
while php.ini stares it should be off
--
Edit this bug report at http://bugs.php.net/bug.php?id=38120&edit=1
Bug #37738 [Opn->Bgs]: basename does not work with Japanese
Edit report at http://bugs.php.net/bug.php?id=37738&edit=1
ID: 37738
Updated by: cataphr...@php.net
Reported by:joey at alegria dot co dot jp
Summary:basename does not work with Japanese
-Status: Open
+Status: Bogus
Type: Bug
Package:*Directory/Filesystem functions
Operating System: Fedora Core 4
PHP Version:5CVS-2006-06-08 (CVS)
Block user comment: N
Private report: N
New Comment:
For better or worse, basename is affected by the locale. The encoding
used in the filenames must match the set locale.
Bogus.
Previous Comments:
[2011-04-10 22:23:10] c...@php.net
I am reopening this as PHP 6 is not developed any more and the bug is
still valid.
[2006-06-08 06:37:11] der...@php.net
Won't fix in PHP 5. This will be implemented for PHP 6.
[2006-06-08 06:09:54] joey at alegria dot co dot jp
Description:
Simply put, basename() does ot work with Japanese filepaths. If the
filename is Japanese only the extension part of the filename is
returned. So a filename "/folder/t@C¼.txt" resolves to just
".txt". I discovered the problem when performing a basename() on the
$_FILES array's 'name' element for uploaded Japanese files, however
after testing the bug occurs no matter how you supply the filename.
My PHP environment is running with UTF-8 internal encoding.
The code snippet below illustrates this perfectly.
Reproduce code:
---
Expected result:
The full filename of the romanized file is
/myfolder/roman_filename.txt.
The basename of the romanized file is roman_filename.txt.
The full filename of the Japanese file is
/myfolder/ú{êÌt@C¼.txt.
The basename of the Japanese file is ú{êÌt@C¼.txt.
Actual result:
--
The full filename of the romanized file is
/myfolder/roman_filename.txt.
The basename of the romanized file is roman_filename.txt.
The full filename of the Japanese file is
/myfolder/ú{êÌt@C¼.txt.
The basename of the Japanese file is .txt.
--
Edit this bug report at http://bugs.php.net/bug.php?id=37738&edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: threedigitnumber at gmail dot com Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. Previous Comments: [2010-12-20 00:47:59] tanguy dot pruvot at gmail dot com Please reopen this issue... "php -m" with php_curl : 3 seconds on a SSD disk "php -m" without curl : instant output Please read the previous answers, seems related to libeay32 ... [2010-12-13 12:41:47] beta dot tests at hotmail dot com On the binaries and sources releases for windows i hope that this PHP 5.3 (5.3.4) isnt the final relese because i once i install the cURL is see a delay of at least 700ms to 1020ms, on windows xp 32bit using FastCGI [2010-12-03 00:14:14] paj...@php.net Fixed in 5.3.4RC2, it will be present in 5.3 final. [2010-09-17 21:37:43] paj...@php.net The problem has been diagnosed, however it is not sure yet how and when it can be fixed. See the other comments for the details. [2010-09-17 18:58:02] misc at themeads dot net Some additional data... I happened to still have 5.2.5 and 5.2.6 around on the harddrive, I dropped the php_curl.dll from each into my php5.2.14 installation, and they both were snappy and no delay. I put the 5.2.13 php_curl.dll back in there, and back to the 5-7 second delay. Note that the delay occurs whether you're actually exercising curl functions or not... i.e., a simple page with only phpinfo() call will also result in the same slowness. So it's just the act of loading the extension (which again, lends credence to the "initialization" cause... but again, this simply didn't exist in earlier versions of the extension, so the initialization changed, and introduced this delay. The submitter of this article indicated it was observed in 5.2.11, my testing confirmed it's in 5.2.13 as well. I'd be curious to see results of testing from 5.2.6 thru 5.2.11 to see where this delay was introduced, but unfortunately don't have copies of php in all those versions. 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/bug.php?id=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: tanguy at pruvot dot tk Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl Previous Comments: [2011-04-11 05:29:56] threedigitnumber at gmail dot com Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. [2010-12-20 00:47:59] tanguy dot pruvot at gmail dot com Please reopen this issue... "php -m" with php_curl : 3 seconds on a SSD disk "php -m" without curl : instant output Please read the previous answers, seems related to libeay32 ... [2010-12-13 12:41:47] beta dot tests at hotmail dot com On the binaries and sources releases for windows i hope that this PHP 5.3 (5.3.4) isnt the final relese because i once i install the cURL is see a delay of at least 700ms to 1020ms, on windows xp 32bit using FastCGI [2010-12-03 00:14:14] paj...@php.net Fixed in 5.3.4RC2, it will be present in 5.3 final. [2010-09-17 21:37:43] paj...@php.net The problem has been diagnosed, however it is not sure yet how and when it can be fixed. See the other comments for the details. 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/bug.php?id=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: tanguy at pruvot dot tk Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: arf, link was truncated : http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl Previous Comments: [2011-04-11 05:39:10] tanguy at pruvot dot tk You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl [2011-04-11 05:29:56] threedigitnumber at gmail dot com Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. [2010-12-20 00:47:59] tanguy dot pruvot at gmail dot com Please reopen this issue... "php -m" with php_curl : 3 seconds on a SSD disk "php -m" without curl : instant output Please read the previous answers, seems related to libeay32 ... [2010-12-13 12:41:47] beta dot tests at hotmail dot com On the binaries and sources releases for windows i hope that this PHP 5.3 (5.3.4) isnt the final relese because i once i install the cURL is see a delay of at least 700ms to 1020ms, on windows xp 32bit using FastCGI [2010-12-03 00:14:14] paj...@php.net Fixed in 5.3.4RC2, it will be present in 5.3 final. 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/bug.php?id=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Req #42958 [Fbk]: [PATCH] Heredoc string constant folding
Edit report at http://bugs.php.net/bug.php?id=42958&edit=1 ID: 42958 Updated by: gop...@php.net Reported by:gop...@php.net Summary:[PATCH] Heredoc string constant folding Status: Feedback Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5CVS-2007-10-13 (CVS) Block user comment: N Private report: N New Comment: New location for the same patch http://notmysock.org/code/zend_add_string_ver2.patch Previous Comments: [2011-04-08 21:14:49] j...@php.net Has this patch been applied yet..? [2007-10-13 22:04:35] gop...@php.net Find the patch/diff at http://t3.dotgnu.info/code/zend_add_string.patch [2007-10-13 22:00:51] gop...@php.net Description: Heredocs in php generates too many opcodes. The tokenizer seems to be hooked directly into the zend_do_add_string() call which creates a new opcode irrespective of previous opcode, where it could do better to just check whether data can be piggy-backed onto the previous opcode. Reproduce code: --- php52 -dvld.active heredoc.php Expected result: filename: /tmp/heredoc.php function name: (null) number of ops: 5 line # op fetch ext operands --- 4 0 INIT_STRING ~0 1 ADD_STRING ~0, ~0, 'heredocs+are+fubar' 5 2 ECHO ~0 7 3 RETURN 1 4 ZEND_HANDLE_EXCEPTION Actual result: -- filename: /tmp/heredoc.php function name: (null) number of ops: 10 line # op fetch ext operands --- 4 0 INIT_STRING ~0 1 ADD_STRING ~0, ~0, 'heredocs' 2 ADD_STRING ~0, ~0, '+' 3 ADD_STRING ~0, ~0, 'are' 4 ADD_STRING ~0, ~0, '+' 5 ADD_STRING ~0, ~0, 'fubar' 5 6 ADD_STRING ~0, ~0, '' 7 ECHO ~0 7 8 RETURN 1 9 ZEND_HANDLE_EXCEPTION -- Edit this bug report at http://bugs.php.net/bug.php?id=42958&edit=1
