Bug #62648 [Com]: similar_text() returns wrong values
Edit report at https://bugs.php.net/bug.php?id=62648&edit=1
ID: 62648
Comment by: carloschilazo at gmail dot com
Reported by:normadize at gmail dot com
Summary:similar_text() returns wrong values
Status: Open
Type: Bug
Package:Strings related
Operating System: Linux, Win32
PHP Version:5.3.15
Block user comment: N
Private report: N
New Comment:
the only thing that I'd want to clear out first about this, is the performance
of
your algorithm vs the built-in function.
Could you please provide the test case you are using to measure this?
Thanks!
Previous Comments:
[2012-07-29 05:48:14] normadize at gmail dot com
Note that besides giving different results when swapping arguments, it gives
wrong results sometimes completely. Here's an example:
Gives 34,32 instead of 35,35.
Longest common substring is "studofironoxidedextrintinbcdtudgafd" which is 35
chars long.
I have written a small custom PHP extension that I compile and load in all my
PHP deployments for speed because a PHP implementation of the longest common
substring algorithm in PHP is painfully slow. My extension is based on suffix
trees rather than recursive calls, which is generally faster for short to
moderately long strings.
Isn't any dev interested in fixing this very useful function? It's been such a
long time ...
I can post my extension code and will attempt to patch the original
similar_text() too.
[2012-07-24 06:17:33] normadize at gmail dot com
Description:
similar_text() returns wrong values, see below for reproducible error.
This is actually a very old bug ... would be nice if someone finally fixed it.
Test script:
---
echo similar_text("test","wert");
echo "|";
echo similar_text("wert","test");
Expected result:
2|2
Actual result:
--
1|2
--
Edit this bug report at https://bugs.php.net/bug.php?id=62648&edit=1
Bug #62907 [Asn->Csd]: Double free when use traits
Edit report at https://bugs.php.net/bug.php?id=62907&edit=1 ID: 62907 Updated by: dmi...@php.net Reported by:larue...@php.net Summary:Double free when use traits -Status: Assigned +Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.4.6 Assigned To:dmitry 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-09-05 06:02:15] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6c0508f8d5d5a62adb37a76bc682c94540199ee3 Log: Fixed bug #62907 (Double free when use traits) [2012-09-04 08:12:31] dmi...@php.net The following patch has been added/updated: Patch Name: alias.diff Revision: 1346746351 URL: https://bugs.php.net/patch-display.php?bug=62907&patch=alias.diff&revision=1346746351 [2012-08-26 10:33:08] larue...@php.net Unless we re-implement the whole alias thing, drop the tricky. we could not fix this properly, even we can do some works in the abstrct methods copy, but it still in a wrong way. Dmitry, could you please look at this? thanks [2012-08-23 15:32:28] larue...@php.net assign to my self. [2012-08-23 15:31:43] larue...@php.net Description: This bug is related to #61998, but was spotting when I fixing the bug #62358, PS: it really tough to refine this reproduce script :) Test script: --- https://bugs.php.net/bug.php?id=62907&edit=1
Bug #62991 [Asn->Csd]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Updated by: dmi...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) -Assigned To:nikic +Assigned To:dmitry 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-09-04 07:09:26] larue...@php.net the static variable table should also be copied, and this func will be copied once / per closure called (create a new genartor). maybe add a new ACC flag is much more simple... which we have discussed before( I also discussed that with nikic :)) [2012-09-04 06:57:58] dmi...@php.net I've added a much simpler patch. Please take a look. [2012-09-02 11:50:39] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.phpt Revision: 1346586639 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.phpt&revision=1346586639 [2012-09-02 11:46:56] larue...@php.net a new patch has been attached, fixed the memleak issue, but the way is a little tricky, used the op_array->reserved fields. so I attached it here instead of ci it, wait for if we can find a better way [2012-09-02 11:45:06] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346586306 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346586306 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62991 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #61767 [Ana]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1 ID: 61767 Updated by: larue...@php.net Reported by:shiranai7 at hotmail dot com Summary:Shutdown functions not called in certain error situation Status: Analyzed Type: Bug Package:Scripting Engine problem Operating System: Win7 PHP Version:5.4.0 -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N New Comment: could you please look at this? since it is in shutdown pharse, then I think it's okey to suppress the exception? thanks Previous Comments: [2012-05-28 16:49:06] shiranai7 at hotmail dot com Still the same (unexpected) result in 5.4.3. Error handler called Fatal error: Call to a member function foo() on a non-object in ... on line ... [2012-04-24 11:37:12] shiranai7 at hotmail dot com I wonder if this fix will make it to the 5.4.1 release. [2012-04-20 09:50:14] larue...@php.net The following patch has been added/updated: Patch Name: another_fix_for_bug61767.patch Revision: 1334915414 URL: https://bugs.php.net/patch-display.php?bug=61767&patch=another_fix_for_bug61767.patch&revision=1334915414 [2012-04-20 06:02:25] larue...@php.net I attached a fix for this, maybe need dmitry to review it. [2012-04-20 06:01:10] larue...@php.net The following patch has been added/updated: Patch Name: bug61767.patch Revision: 1334901670 URL: https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.patch&revision=1334901670 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=61767 -- Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #63012 [Opn->Dup]: register_shutdown_function is not called after error in __toString
Edit report at https://bugs.php.net/bug.php?id=63012&edit=1 ID: 63012 Updated by: larue...@php.net Reported by:david at grudl dot com Summary:register_shutdown_function is not called after error in __toString -Status: Open +Status: Duplicate Type: Bug Package:Scripting Engine problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: oh, sorry, I was wrong, this is similar as #61767, see https://bugs.php.net/bug.php?id=61767 thanks Previous Comments: [2012-09-05 03:04:10] larue...@php.net it's a compile error, not a runtime error. so,, it's expected behavior [2012-09-04 17:55:47] david at grudl dot com Description: Functions registered using register_shutdown_function are called after all fatal errors, except error "Method __toString() must not throw an exception". Test script: --- https://bugs.php.net/bug.php?id=63012&edit=1
Bug #63012 [Opn]: register_shutdown_function is not called after error in __toString
Edit report at https://bugs.php.net/bug.php?id=63012&edit=1 ID: 63012 Updated by: larue...@php.net Reported by:david at grudl dot com Summary:register_shutdown_function is not called after error in __toString Status: Open Type: Bug Package:Scripting Engine problem PHP Version:Irrelevant Block user comment: N Private report: N New Comment: it's a compile error, not a runtime error. so,, it's expected behavior Previous Comments: [2012-09-04 17:55:47] david at grudl dot com Description: Functions registered using register_shutdown_function are called after all fatal errors, except error "Method __toString() must not throw an exception". Test script: --- https://bugs.php.net/bug.php?id=63012&edit=1
Req #52583 [Opn]: Improved casting and hinting, new magic method __cast()
Edit report at https://bugs.php.net/bug.php?id=52583&edit=1 ID: 52583 Updated by: ahar...@php.net Reported by:martin dot leucht at gmail dot com Summary:Improved casting and hinting, new magic method __cast() Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Not a dupe: request #46128 covers casting the other way. (That alone is probably a good argument for changing the proposed magic method name.) Previous Comments: [2012-09-04 14:20:42] qfox at ya dot ru dup?: https://bugs.php.net/bug.php?id=46128&thanks=6 [2010-10-19 11:41:50] rayro at gmx dot de pretty nice, awesome feature! but i have some recommendations on this: 1) is it true that i cannot cast to a boolean false? what about throwing the error if no return was made? the user is able to throw some exception or will simple not return anything to use the default error mechanism... 2) i think there should be 2 additional types of functions covering your 2 solutions by simply change the name. for your case 1 this should be __cast, whereas 2 could be __hint? the essential difference is that __hint will be called in the functions arguments and __cast will be called elsewhere? [2010-10-03 18:45:29] + at ni-po dot com @degeberg: Doesn't the RFC cover casting the other way round? I.e. Class -> Scalar [2010-08-11 16:54:01] degeb...@php.net See: http://wiki.php.net/rfc/class_casting_to_scalar [2010-08-11 16:30:02] martin dot leucht at gmail dot com Description: Type casting in PHP is currently limited to the builtin types. It would be very useful (IMO) if one could cast a value/variable to a class. And also type hinting could be improved by casting instead of type checking only. I suggest to solve this by introducing a new magic method for classes, called "__cast()", that accepts the value to cast as parameter. I see two possible solutions for its functionality: (1) __cast() replaces the constructor method This will force the developer to move logics from the constructor into a separate function/method (which isn't even so bad) or to copy his code (which is indeed bad). If the function returns with the boolean value "false", the default error mechanism is started saying something like "cast to XYZ not allowed". (2) __cast() acts like a static constructor The code must return the casted result itself. That means one would implement some logics to transform the given value to the needed constructor parameters and create a new instance on his own. To handle an unsupported value the method would throw an exception or an error. The negative (or let's say curious) thing about this solution is, that this cast method could also return a value of a totally different type (see example). Test script: --- // see patch file Expected result: // working cast Actual result: -- // parse errors -- Edit this bug report at https://bugs.php.net/bug.php?id=52583&edit=1
Req #41245 [Opn]: Ability to set handler for "memory limit exceeded"
Edit report at https://bugs.php.net/bug.php?id=41245&edit=1 ID: 41245 Updated by: ras...@php.net Reported by:bens at effortlessis dot com Summary:Ability to set handler for "memory limit exceeded" Status: Open Type: Feature/Change Request Package:*General Issues Operating System: Any PHP Version:4.4.6 Block user comment: N Private report: N New Comment: Oh, and why wouldn't you just use a shutdown function for this? If you do all your processing before sending any output and then check for an out of memory in the shutdown function you can easily do this redirect in this case. Previous Comments: [2012-09-04 20:18:22] ras...@php.net That is rather tricky because such a callback could continue consuming memory. We would have to introduce the concept of soft and hard limits or something along those lines for this to be realistic. [2012-09-04 19:58:07] slusarz at curecanti dot org This would be tremendously useful, especially when the cause of the memory overrun is not the PHP code but rather due to the data input to the script. For example: In Horde/IMP, we need to parse MIME e-mail messages. These e-mail messages contain data that potentially could be unfiltered. A particular mail message script MUST parse the entire data input in order to show anything (you cannot truncate MIME data, or else the resulting MIME message is invalid). Even using things like temporary data streams, there is still a chance that the memory limit can be exceeded. It would be tremendously useful to be able to define a memory limit exceeded handler for any given script that could catch the case where we can not parse the message due to a memory limit caused by the message data itself. This handler could allow the script to do something like automatically redirect the browser to a different page and display an error message. [2007-04-30 19:33:55] bens at effortlessis dot com Description: When Memory Limit is exceeded, PHP simply terminates, which shows as a "blank white screen". It would be very helpful if a callback function or simply an optional header redirect could be emitted when memory limit is exceeded. It could be as simple as an option in php.ini which would work like the "ErrorDocument" apache directive, so that an attractive, "What you asked for used up too much memory, so sorry!" page could be displayed rather than just an uninformative and unfriendly blank screen. This idea could perhaps be expanded to a default "PHP died" handler, so that a friendly "something went wrong" page could be displayed. Reproduce code: --- $somevar=''; for ($i=0; $i<2; $i++) $somevar.="bb"; Expected result: Program output: Location: /value/set/in/php.ini/or/apache/directive/helpful.html Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 Actual result: -- Program output: Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 -- Edit this bug report at https://bugs.php.net/bug.php?id=41245&edit=1
Req #41245 [Opn]: Ability to set handler for "memory limit exceeded"
Edit report at https://bugs.php.net/bug.php?id=41245&edit=1 ID: 41245 Updated by: ras...@php.net Reported by:bens at effortlessis dot com Summary:Ability to set handler for "memory limit exceeded" Status: Open Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Any PHP Version:4.4.6 Block user comment: N Private report: N New Comment: That is rather tricky because such a callback could continue consuming memory. We would have to introduce the concept of soft and hard limits or something along those lines for this to be realistic. Previous Comments: [2012-09-04 19:58:07] slusarz at curecanti dot org This would be tremendously useful, especially when the cause of the memory overrun is not the PHP code but rather due to the data input to the script. For example: In Horde/IMP, we need to parse MIME e-mail messages. These e-mail messages contain data that potentially could be unfiltered. A particular mail message script MUST parse the entire data input in order to show anything (you cannot truncate MIME data, or else the resulting MIME message is invalid). Even using things like temporary data streams, there is still a chance that the memory limit can be exceeded. It would be tremendously useful to be able to define a memory limit exceeded handler for any given script that could catch the case where we can not parse the message due to a memory limit caused by the message data itself. This handler could allow the script to do something like automatically redirect the browser to a different page and display an error message. [2007-04-30 19:33:55] bens at effortlessis dot com Description: When Memory Limit is exceeded, PHP simply terminates, which shows as a "blank white screen". It would be very helpful if a callback function or simply an optional header redirect could be emitted when memory limit is exceeded. It could be as simple as an option in php.ini which would work like the "ErrorDocument" apache directive, so that an attractive, "What you asked for used up too much memory, so sorry!" page could be displayed rather than just an uninformative and unfriendly blank screen. This idea could perhaps be expanded to a default "PHP died" handler, so that a friendly "something went wrong" page could be displayed. Reproduce code: --- $somevar=''; for ($i=0; $i<2; $i++) $somevar.="bb"; Expected result: Program output: Location: /value/set/in/php.ini/or/apache/directive/helpful.html Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 Actual result: -- Program output: Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 -- Edit this bug report at https://bugs.php.net/bug.php?id=41245&edit=1
Req #41245 [Com]: Ability to set handler for "memory limit exceeded"
Edit report at https://bugs.php.net/bug.php?id=41245&edit=1 ID: 41245 Comment by: slusarz at curecanti dot org Reported by:bens at effortlessis dot com Summary:Ability to set handler for "memory limit exceeded" Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Any PHP Version:4.4.6 Block user comment: N Private report: N New Comment: This would be tremendously useful, especially when the cause of the memory overrun is not the PHP code but rather due to the data input to the script. For example: In Horde/IMP, we need to parse MIME e-mail messages. These e-mail messages contain data that potentially could be unfiltered. A particular mail message script MUST parse the entire data input in order to show anything (you cannot truncate MIME data, or else the resulting MIME message is invalid). Even using things like temporary data streams, there is still a chance that the memory limit can be exceeded. It would be tremendously useful to be able to define a memory limit exceeded handler for any given script that could catch the case where we can not parse the message due to a memory limit caused by the message data itself. This handler could allow the script to do something like automatically redirect the browser to a different page and display an error message. Previous Comments: [2007-04-30 19:33:55] bens at effortlessis dot com Description: When Memory Limit is exceeded, PHP simply terminates, which shows as a "blank white screen". It would be very helpful if a callback function or simply an optional header redirect could be emitted when memory limit is exceeded. It could be as simple as an option in php.ini which would work like the "ErrorDocument" apache directive, so that an attractive, "What you asked for used up too much memory, so sorry!" page could be displayed rather than just an uninformative and unfriendly blank screen. This idea could perhaps be expanded to a default "PHP died" handler, so that a friendly "something went wrong" page could be displayed. Reproduce code: --- $somevar=''; for ($i=0; $i<2; $i++) $somevar.="bb"; Expected result: Program output: Location: /value/set/in/php.ini/or/apache/directive/helpful.html Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 Actual result: -- Program output: Logfile output: [client 63.195.17.22] PHP Fatal error: Allowed memory size of 100663296 bytes exhausted (tried to allocate 11870154 bytes) in /path/to/php/file.php on line 216, referer: http://mysite.com/path/to/php/file.php?PHPSESSID=2a39d521e3660f0a4fc2132dc34e1e68 -- Edit this bug report at https://bugs.php.net/bug.php?id=41245&edit=1
Req #62574 [Com]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 Comment by: ajf at ajf dot me Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: (I'm all for this though, I'm just pointing out other options) Previous Comments: [2012-09-04 18:06:32] ajf at ajf dot me You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) [2012-07-16 04:07:43] thbley at gmail dot com Description: old: new: echo <$str>; ?> or: -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
Req #62574 [Com]: New operator for htmlspecialchars
Edit report at https://bugs.php.net/bug.php?id=62574&edit=1 ID: 62574 Comment by: ajf at ajf dot me Reported by:thbley at gmail dot com Summary:New operator for htmlspecialchars Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: You can escape things ahead-of-time, you know. In fact, I have a feeling you could use foreach to traverse the symtable and escape everything. (don't do that though, that's a horrendous idea) Previous Comments: [2012-07-16 04:07:43] thbley at gmail dot com Description: old: new: echo <$str>; ?> or: -- Edit this bug report at https://bugs.php.net/bug.php?id=62574&edit=1
[PHP-BUG] Bug #63012 [NEW]: register_shutdown_function is not called after error in __toString
From: david at grudl dot com Operating system: PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Bug Bug description:register_shutdown_function is not called after error in __toString Description: Functions registered using register_shutdown_function are called after all fatal errors, except error "Method __toString() must not throw an exception". Test script: --- https://bugs.php.net/bug.php?id=63012&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63012&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63012&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63012&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63012&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63012&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63012&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63012&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63012&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63012&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63012&r=support Expected behavior: https://bugs.php.net/fix.php?id=63012&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63012&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63012&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63012&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63012&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63012&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63012&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63012&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63012&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63012&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63012&r=mysqlcfg
Bug #62769 [Com]: Inconsistent notice reporting using []
Edit report at https://bugs.php.net/bug.php?id=62769&edit=1
ID: 62769
Comment by: ajf at ajf dot me
Reported by:julien at palard dot fr
Summary:Inconsistent notice reporting using []
Status: Open
Type: Bug
Package:Output Control
PHP Version:5.4.5
Block user comment: N
Private report: N
New Comment:
Well, according to someone in internals whose name I forgot, NULL[$anything] is
implicitly NULL. Which I think is rather absurd, personally. I don't see why
it's
not an error.
Previous Comments:
[2012-08-08 07:10:11] julien at palard dot fr
larue...@php.net : Nice for const array dereference :-)
But what about the point of the ticket :
$foo = NULL;
echo $foo["bar"];
that fails silently ?
[2012-08-08 02:36:41] larue...@php.net
const array dereference is only in trunk
[2012-08-07 14:42:36] julien at palard dot fr
Description:
Error reported for invalid [] access seems inconsistent :
echo NULL["bar"] -> Parse error
echo []["bar"] -> Parse error
$foo = NULL; echo $foo["bar"] -> Fails silently
$foo = []; echo $foo["bar"] -> Notice: Undefined index
class Bar {} ; $foo = new Bar(); echo $foo["bar"]; -> PHP Fatal error
I whish :
[]["bar"] to trigger Notice: Undefined index
NULL["bar"] to trigger something catcheable with set_error_handler
$foo = NULL; $foo["bar"] to trigger a catcheable Notice.
Test script:
---
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo []["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); echo NULL["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = NULL; $foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); $foo = []; $foo["bar"];'
/usr/local/php-5.4.5/bin/php -r 'error_reporting(-1); class Bar {} ; $foo = new
Bar(); echo $foo["bar"];'
Expected result:
At least get a Notice on :
$foo = NULL;
echo $foo["bar"];
Actual result:
--
Fails silently.
--
Edit this bug report at https://bugs.php.net/bug.php?id=62769&edit=1
Bug #62934 [Com]: mb_convert_kana() does not convert iteration marks
Edit report at https://bugs.php.net/bug.php?id=62934&edit=1 ID: 62934 Comment by: ajf at ajf dot me Reported by:scin dot ichi at gmail dot com Summary:mb_convert_kana() does not convert iteration marks Status: Open Type: Bug Package:mbstring related Operating System: any platform PHP Version:5.3.16 Block user comment: N Private report: N New Comment: Had a look. Turns out this is an issue with libmbfl, which mbstring uses. Not sure if it can be updated or not, someone else should look into it. But it's not an issue with mbstring itself, mb_convert_kana passes through to mbl_ja_jp_hantozen. Previous Comments: [2012-08-26 11:03:05] scin dot ichi at gmail dot com Description: mb_convert_kana() does not convert japanese iteration marks (odori-ji). * Hiragana to Katakana ($option = 'C') ã and ã must be converted ã½ and ã¾ * Katakana to Hiragana ($option = 'c') ã½ and ã¾ must be converted ã and ã Test script: --- https://bugs.php.net/bug.php?id=62934&edit=1
Bug #60909 [Opn]: custom error handler throwing Exception + fatal error = no shutdown function
Edit report at https://bugs.php.net/bug.php?id=60909&edit=1
ID: 60909
Updated by: bis...@php.net
Reported by:tyr...@php.net
Summary:custom error handler throwing Exception + fatal
error = no shutdown function
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: linux
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
@nikic: I can generate the same path without the first non-fatal error:
--
register_shutdown_function(function(){echo("\n\n!!!shutdown!!!\n\n");});
set_error_handler(function($errno, $errstr, $errfile, $errline){throw new
Exception("Foo");});
class Bad {
public function __toString() {
throw new Exception('Oops, I cannot do this');
}
}
$bad = new Bad();
echo "$bad";
--
This is on 5.3.10, like @jpauli report, and 5.4.6 as well.
The @laruence EG(exception) = NULL patch handles this case as well. AFAIK,
that patch is appropriate.
Previous Comments:
[2012-04-20 00:15:50] ni...@php.net
I tried adding an EG(exception) = NULL; at the start of php_request_shutdown()
and it indeed fixes the issue. Though probably that's not the right way to fix
this.
[2012-04-19 23:40:57] ni...@php.net
So, this is what I think is happening here:
1. The first non-fatal error (here warning) throws an Exception, i.e. sets
EG(exception)
2. The second fatal error then causes a zend_bailout() moving us directly to
php_request_shutdown()
3. During the shutdown sequence PHP will try to call the shutdown handler using
call_user_function().
4. As EG(exception) is still set, the call is not allows (see
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_execute_API.c#775).
[2012-04-19 23:06:26] ni...@php.net
Together with https://bugs.php.net/bug.php?id=61767 it is a bit more clear
under which circumstances this occurs:
1. A non-fatal error is thrown
2. The error handler throws an Exception
3. A fatal error is thrown
In this particular case:
1. require() throws an E_WARNING (Warning: require(notfound.php): failed to
open stream: No such file or directory).
2. The error handler throws the Exception
3. require() throws an E_COMPILE_ERROR (Fatal error: require(): Failed opening
required 'notfound.php')
[2012-02-09 14:33:57] jpa...@php.net
Ok I can reproduce.
Try replacing your require (which generates E_COMPILE_ERROR) by an unknown
function call (which generates E_ERROR), and all's just fine
So there is a trick in the error engine, any kind of fatal shouldn't be handled
by user defined error handlers, here we got proof it's not the case
Tip: Reproduced on 5.3.10 as well
[2012-01-27 18:07:20] tyr...@php.net
Description:
first of all sorry for the weird Summary, I couldn't come up with a better one.
it is weird.
so it seems that if you have a shutdown function callback set and a custom
error
handler which would throw and exception and you happen to have a fatal error,
the shutdown function won't be called.
See the attached script, the error handler shouldn't really do anything here,
because it won't be called for the fatals, but somehow it still screw things up.
If I remove the error handler, I will see the "!!!shutdown!!!" printed.
If I put a "return false;" before the throw I will see the "!!!shutdown!!!"
printed.
If I add E_NOTICE as the $error_type to the set_error_handler call I will see
the "!!!shutdown!!!" printed.
If I add E_WARNING as the $error_type to the set_error_handler call I will NOT
see the "!!!shutdown!!!" printed.
wtf?
Test script:
---
https://bugs.php.net/bug.php?id=60909&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Comment by: janfili+phpbugs at gmail dot com Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: This is a real duplicate: https://bugs.php.net/bug.php?id=45959 And it ended in fixing the Documentation. What is fine. But the Documentation did not get Update everywhere. This page covers it just fine. http://www.php.net/manual/en/ language.types.array.php#language.types.arr ay.casting But this one doesnt http://www.php.net/manual/de/ language.types.array.php#language.types.arr ay.casting I see the language parameter in the url, but it in english all the time. Can someone make all the pages up to date. Previous Comments: [2012-09-04 14:38:20] reeze dot xia at gmail dot com Hi janfili, It IS a bug, @see https://bugs.php.net/bug.php?id=61655 object -> array have problem, so does array -> object have the same problem. It is inconsistent, but it was documented. [2012-09-04 14:37:23] larue...@php.net would you read my comment clearly(or the comment of scott...@php.net in #51951)? as I said, the key has become to a string... I knew what you are saying, but as I said, it's a knew behavior(or knew issue)... [2012-09-04 14:16:03] janfili+phpbugs at gmail dot com Would you please read my comments carefully again? as i mentioned in earlier comments it is NOT possible to get the values using 1. var_dump($array[1]); or 2. var_dump($array['1']); or 3. var_dump($array["1"]); or 4. $k = array_keys($array); var_dum($array[$k[0]]); All of these options will result into undefined index. Even though the keys we convertet to strings, you cant get the values by using the string key. You cant even get the value if you get the keys by array_keys() first. Before posting something about string keys vs int keys now, just take a close look at 4. best regards [2012-09-04 13:17:45] larue...@php.net they are the same the array's key 1 has become to string "1".. [2012-09-04 11:39:27] janfili+phpbugs at gmail dot com not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #62985 [Opn->Wfx]: set_exception_handler doesn't work from command line
Edit report at https://bugs.php.net/bug.php?id=62985&edit=1
ID: 62985
Updated by: larue...@php.net
Reported by:lgandras at gmail dot com
Summary:set_exception_handler doesn't work from command line
-Status: Open
+Status: Wont fix
Type: Bug
Package:*Configuration Issues
Operating System: CentoOS 6.2 x64
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
since you have got a alternative way,, then I'd like this be marked as wont'fix
Previous Comments:
[2012-08-31 18:14:42] lgandras at gmail dot com
Temporary solution
echo 'https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346434197
[2012-08-31 17:28:35] larue...@php.net
a quick fix has been attached. but it is a change of zend API, so maybe someone
else will have objections
[2012-08-31 17:25:47] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62985.patch
Revision: 1346433947
URL:
https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346433947
[2012-08-31 16:40:05] lgandras at gmail dot com
Description:
This is the output of my console:
# /usr/local/bin/php -v
PHP 5.3.16 (cli) (built: Aug 30 2012 18:38:54)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
# /usr/local/bin/php -r 'set_exception_handler(function(){echo
"catched\n";});throw new Exception;'
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
root@vps:~#
Test script:
---
# /usr/local/bin/php -r 'set_exception_handler(function($e){echo
"catched!\n";});throw new Exception;'
Expected result:
catched!
Actual result:
--
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=62985&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Comment by: reeze dot xia at gmail dot com Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: Hi janfili, It IS a bug, @see https://bugs.php.net/bug.php?id=61655 object -> array have problem, so does array -> object have the same problem. It is inconsistent, but it was documented. Previous Comments: [2012-09-04 14:37:23] larue...@php.net would you read my comment clearly(or the comment of scott...@php.net in #51951)? as I said, the key has become to a string... I knew what you are saying, but as I said, it's a knew behavior(or knew issue)... [2012-09-04 14:16:03] janfili+phpbugs at gmail dot com Would you please read my comments carefully again? as i mentioned in earlier comments it is NOT possible to get the values using 1. var_dump($array[1]); or 2. var_dump($array['1']); or 3. var_dump($array["1"]); or 4. $k = array_keys($array); var_dum($array[$k[0]]); All of these options will result into undefined index. Even though the keys we convertet to strings, you cant get the values by using the string key. You cant even get the value if you get the keys by array_keys() first. Before posting something about string keys vs int keys now, just take a close look at 4. best regards [2012-09-04 13:17:45] larue...@php.net they are the same the array's key 1 has become to string "1".. [2012-09-04 11:39:27] janfili+phpbugs at gmail dot com not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum [2012-09-04 11:17:17] larue...@php.net similar to https://bugs.php.net/bug.php?id=51915 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #63007 [Nab]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Updated by: larue...@php.net Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: would you read my comment clearly(or the comment of scott...@php.net in #51951)? as I said, the key has become to a string... I knew what you are saying, but as I said, it's a knew behavior(or knew issue)... Previous Comments: [2012-09-04 14:16:03] janfili+phpbugs at gmail dot com Would you please read my comments carefully again? as i mentioned in earlier comments it is NOT possible to get the values using 1. var_dump($array[1]); or 2. var_dump($array['1']); or 3. var_dump($array["1"]); or 4. $k = array_keys($array); var_dum($array[$k[0]]); All of these options will result into undefined index. Even though the keys we convertet to strings, you cant get the values by using the string key. You cant even get the value if you get the keys by array_keys() first. Before posting something about string keys vs int keys now, just take a close look at 4. best regards [2012-09-04 13:17:45] larue...@php.net they are the same the array's key 1 has become to string "1".. [2012-09-04 11:39:27] janfili+phpbugs at gmail dot com not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum [2012-09-04 11:17:17] larue...@php.net similar to https://bugs.php.net/bug.php?id=51915 [2012-09-04 08:21:08] reeze dot xia at gmail dot com Yes, it will not accessible anymore if you have property with string number. since array handle keys different from objects. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Req #52583 [Com]: Improved casting and hinting, new magic method __cast()
Edit report at https://bugs.php.net/bug.php?id=52583&edit=1 ID: 52583 Comment by: qfox at ya dot ru Reported by:martin dot leucht at gmail dot com Summary:Improved casting and hinting, new magic method __cast() Status: Open Type: Feature/Change Request Package:Class/Object related Operating System: Irrelevant PHP Version:Irrelevant Block user comment: N Private report: N New Comment: dup?: https://bugs.php.net/bug.php?id=46128&thanks=6 Previous Comments: [2010-10-19 11:41:50] rayro at gmx dot de pretty nice, awesome feature! but i have some recommendations on this: 1) is it true that i cannot cast to a boolean false? what about throwing the error if no return was made? the user is able to throw some exception or will simple not return anything to use the default error mechanism... 2) i think there should be 2 additional types of functions covering your 2 solutions by simply change the name. for your case 1 this should be __cast, whereas 2 could be __hint? the essential difference is that __hint will be called in the functions arguments and __cast will be called elsewhere? [2010-10-03 18:45:29] + at ni-po dot com @degeberg: Doesn't the RFC cover casting the other way round? I.e. Class -> Scalar [2010-08-11 16:54:01] degeb...@php.net See: http://wiki.php.net/rfc/class_casting_to_scalar [2010-08-11 16:30:02] martin dot leucht at gmail dot com Description: Type casting in PHP is currently limited to the builtin types. It would be very useful (IMO) if one could cast a value/variable to a class. And also type hinting could be improved by casting instead of type checking only. I suggest to solve this by introducing a new magic method for classes, called "__cast()", that accepts the value to cast as parameter. I see two possible solutions for its functionality: (1) __cast() replaces the constructor method This will force the developer to move logics from the constructor into a separate function/method (which isn't even so bad) or to copy his code (which is indeed bad). If the function returns with the boolean value "false", the default error mechanism is started saying something like "cast to XYZ not allowed". (2) __cast() acts like a static constructor The code must return the casted result itself. That means one would implement some logics to transform the given value to the needed constructor parameters and create a new instance on his own. To handle an unsupported value the method would throw an exception or an error. The negative (or let's say curious) thing about this solution is, that this cast method could also return a value of a totally different type (see example). Test script: --- // see patch file Expected result: // working cast Actual result: -- // parse errors -- Edit this bug report at https://bugs.php.net/bug.php?id=52583&edit=1
Req #46128 [Com]: Magic function __cast($to)
Edit report at https://bugs.php.net/bug.php?id=46128&edit=1
ID: 46128
Comment by: qfox at ya dot ru
Reported by:131 dot php at cloudyks dot org
Summary:Magic function __cast($to)
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: Linux
PHP Version:5.2.6
Block user comment: N
Private report: N
New Comment:
WHEEN?!!
There was 3 years to patch sources!
Previous Comments:
[2011-01-20 22:54:12] neoegm at hotmail dot com
This would be very useful in order to be able to define a specific evaluation
method for an object as a boolean, to, for example, simplify if-switches, so
you can just do:
if ($obj)
{
//...
}
Here an example of a class which toggles its own value each time it's evaluated
as a boolean:
class ToggleObj
{
var $val = FALSE;
function __toBool()
{
$ret = $this->val;
$this->val = !$ret;
return $ret;
}
}
$obj = new ToggleObj;
if ($obj)
{
//Does not enter
}
if ($obj)
{
//Now it does
}
Or going further, to make even table rows highlighted:
foreach ($rows as $row)
{
?>
">
http://www.neoegm.com/
[2009-03-28 12:41:30] andrea at 3site dot it
I wonder why you guys do not implement in core the PECL php_operator which
would make code style and life much easier.
I cannot imagine a Number class which needs (int)$obj for every single
operation.
Please do not get me wrong, __cast is a good idea, but it covers only explicit
cases while every other decent language (C#, Java, Python) allows developer to
implement implic cast behavior as well.
This, in PHP 5.3, would be excellent (but probaly an illusion thou).
Regards
[2009-02-06 00:11:19] rayro at gmx dot de
This is such a nice Implementation and very useful, but i prefer to add the
methods __toBool, __toInt and __toArray rather than __cast, stay tuned with
PHP's other magic methods..
I dont agree fully with that post in feature request #38508 from helly. If
that'll be the way, why did the decision for magic methods?
Isnt that all complex although? ^^
We know, but in my eyes (and many others), i think that these magically stuff
is one of the top key features for php. And none of these features will become
critism i think. If not needed, just dont use them!
The additional goody __toInvoke() introduced in 5_3 is a such nice addition for
developing "quick gets" based on nested object sets:
getArticles();
// old way
$magazine->getArticle($magazine->useMagazine(3));
?>
This helper is a "backdoor" like way to enable PHP to fully write nested
Objects like in Javascript. And my opinion for that: I LIKE THIS :)
I think this is a very very discussable topic to the changes for 5_3 or 6_0
beside the wanted support for traditional type hinting and utf8!
thanks
[2008-11-23 09:01:02] mark at hell dot ne dot jp
Please test the following extension :
http://ookoo.org/svn/snip/phpcastable/
This extension adds a "Castable" interface. Any class implementing this
interface have to implement a __cast() function. This function will be called
when the object needs to be casted to a type.
This extension is EXPERIMENTAL and needs more testing/review before being used
in any production system.
[2008-10-27 17:08:24] info at netmosfera dot it
AWESOME!
php developers, please, we need it!!
http://bugs.php.net/bug.php?id=46404
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=46128
--
Edit this bug report at https://bugs.php.net/bug.php?id=46128&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Comment by: janfili+phpbugs at gmail dot com Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: Would you please read my comments carefully again? as i mentioned in earlier comments it is NOT possible to get the values using 1. var_dump($array[1]); or 2. var_dump($array['1']); or 3. var_dump($array["1"]); or 4. $k = array_keys($array); var_dum($array[$k[0]]); All of these options will result into undefined index. Even though the keys we convertet to strings, you cant get the values by using the string key. You cant even get the value if you get the keys by array_keys() first. Before posting something about string keys vs int keys now, just take a close look at 4. best regards Previous Comments: [2012-09-04 13:17:45] larue...@php.net they are the same the array's key 1 has become to string "1".. [2012-09-04 11:39:27] janfili+phpbugs at gmail dot com not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum [2012-09-04 11:17:17] larue...@php.net similar to https://bugs.php.net/bug.php?id=51915 [2012-09-04 08:21:08] reeze dot xia at gmail dot com Yes, it will not accessible anymore if you have property with string number. since array handle keys different from objects. [2012-09-04 08:19:17] reeze dot xia at gmail dot com Ah, I'm sorry, the bug ID: #54082, I can't find the report right now. will post that later The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #63007 [Nab]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Updated by: larue...@php.net Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: they are the same the array's key 1 has become to string "1".. Previous Comments: [2012-09-04 11:39:27] janfili+phpbugs at gmail dot com not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum [2012-09-04 11:17:17] larue...@php.net similar to https://bugs.php.net/bug.php?id=51915 [2012-09-04 08:21:08] reeze dot xia at gmail dot com Yes, it will not accessible anymore if you have property with string number. since array handle keys different from objects. [2012-09-04 08:19:17] reeze dot xia at gmail dot com Ah, I'm sorry, the bug ID: #54082, I can't find the report right now. will post that later [2012-09-04 08:18:29] janfili+phpbugs at gmail dot com using this var_dump($array['1']); as the last statement will not help either The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
[PHP-BUG] Bug #63010 [NEW]: libtool: link: cannot find the library `/lib/libgcrypt.la'
From: showerheadsuk at hotmail dot com Operating system: Ubuntu 12.04 LTS PHP version: 5.4.6 Package: Compile Failure Bug Type: Bug Bug description:libtool: link: cannot find the library `/lib/libgcrypt.la' Description: When I try to make or make test php, compile fails with the error: libtool: link: cannot find the library `/lib/libgcrypt.la' or unhandled argument `/lib/libgcrypt.la' make: *** [sapi/cli/php] Error 1 I have libgcrypt installed in a non-standard location, but I am specifying the location with the LDFLAGS and CPPFLAGS in configure. It is still looking in /lib for the files though, I don't why? Test script: --- LDFLAGS=-L$HOME/apps/libgcrypt/lib CPPFLAGS=-I$HOME/apps/libgcrypt/include ./configure --prefix=$HOME/apps/$PHP \ --enable-mbstring \ --enable-zip \ --enable-fpm \ --enable-ftp \ --with-openssl=$HOME/apps/openssl \ --with-openssl-dir=$HOME/apps/openssl \ --with-jpeg-dir=$HOME/apps/libjpeg-turbo \ --with-gd \ --with-freetype-dir=/usr \ --with-gettext \ --with-xmlrpc \ --with-icu-dir=$HOME/apps/icu4c \ --enable-intl \ --with-pdo-mysql=mysqlnd \ --with-mysql=mysqlnd \ --with-mysqli=mysqlnd \ --with-zlib-dir=/usr \ --with-kerberos=/usr \ --with-png-dir=/usr \ --with-ldap=$HOME/apps/openldap \ --with-curl=$HOME/apps/curl \ --with-mcrypt=$HOME/apps/libmcrypt \ --with-mhash=$HOME/apps/mhash \ --with-tidy=$HOME/apps/tidy \ --with-libxml-dir=$HOME/apps/libxml2 \ --with-iconv-dir=$HOME/apps/libiconv \ --with-xsl=$HOME/apps/libxslt Expected result: Successful compile Actual result: -- libtool: link: cannot find the library `/lib/libgcrypt.la' or unhandled argument `/lib/libgcrypt.la' make: *** [sapi/cli/php] Error 1 -- Edit bug report at https://bugs.php.net/bug.php?id=63010&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63010&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63010&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63010&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63010&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63010&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63010&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63010&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63010&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63010&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63010&r=support Expected behavior: https://bugs.php.net/fix.php?id=63010&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63010&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63010&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63010&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63010&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63010&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63010&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63010&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63010&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63010&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63010&r=mysqlcfg
Bug #63004 [Com]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1
ID: 63004
Comment by: david at grudl dot com
Reported by:juzna dot cz at gmail dot com
Summary:errors json_encode do NOT call error handler
Status: Not a bug
Type: Bug
Package:JSON related
Operating System: Ubuntu 10.04
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
ad "in PHP 5.5 the behavior here changes ⦠error will be available via
json_last_error()"
Functions like mysql_error(), socket_last_error(), preg_last_error() etc are
very unreliable because:
1) you are never sure the error-code was correctly reseted.
example 1:
json_decode('***'); // error, json_last_error() returns 4
json_decode(''); // correct, but it resets json_last_error() only since PHP
5.3.7
example 2:
preg_match('#.#u', "\xCA"); // error, preg_last_error() returns 4
preg_match("#\xCA#u", ''); // error too, but it DO NOT (re)set preg_last_error()
echo preg_last_error(); // preg_last_error() still returns 4
2) sometimes it is impossible to say what is "last" error
$s = preg_replace_callback($pattern, $callback, $s);
if (preg_last_error()) {
// was error in this preg_replace_callback or was PCRE used in $callback?
Nobody knows...
}
Everything can be solved by converting warnings to exceptions via
set_error_handle(). So I hope it will possible in PHP 5.5.
Previous Comments:
[2012-09-04 12:03:21] david at grudl dot com
Common way to avoid warnings in PHP is to use shut-up operator:
$handle = @fopen($file, 'r');
It is not ideal solution, but it is used in whole PHP. Standard. With just one
exception:
$old = ini_set('display_errors', 1);
$json = json_encode($args);
ini_set('display_errors', $old);
Why json_encode() is exception?
[2012-09-04 06:01:05] ni...@php.net
By the way, in PHP 5.5 the behavior here changes and there is no warning at
all. The error will be available via json_last_error() and a second function
which returns a human readable string instead of an error code.
[2012-09-04 03:28:46] ras...@php.net
It isn't a new mechanism for PHP. We have had things like mysql_error(),
socket_last_error(), oci_error(), ldap_error(), pg_last_error(),
libxml_get_errors(), preg_last_error(), curl_error() and many money for a very
long time.
The main reason to not surface a warning here is that the only way to avoid it
would be to call iconv('utf-8','utf-8',$str) on all strings to be encoded. This
is a huge hassle to do, it is slow, and this is something we actually do
internally in json_encode() to validate utf-8 anyway, so it would be entirely
redundant. And since in many cases you end up passing user data or at least 3rd-
party data directly to json_encode() you would have to always add this
redundant
check.
[2012-09-04 03:17:44] david at grudl dot com
This is the only one function in whole PHP with this behaviour. So is it a new
way of error handling or bug?
[2012-09-03 23:36:20] ras...@php.net
json_encode() now checks for valid utf-8. It makes no sense to generate
warnings
for core functionality of the function. You can check json_last_error() for
JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63004
--
Edit this bug report at https://bugs.php.net/bug.php?id=63004&edit=1
Bug #63004 [Com]: errors json_encode do NOT call error handler
Edit report at https://bugs.php.net/bug.php?id=63004&edit=1
ID: 63004
Comment by: david at grudl dot com
Reported by:juzna dot cz at gmail dot com
Summary:errors json_encode do NOT call error handler
Status: Not a bug
Type: Bug
Package:JSON related
Operating System: Ubuntu 10.04
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
Common way to avoid warnings in PHP is to use shut-up operator:
$handle = @fopen($file, 'r');
It is not ideal solution, but it is used in whole PHP. Standard. With just one
exception:
$old = ini_set('display_errors', 1);
$json = json_encode($args);
ini_set('display_errors', $old);
Why json_encode() is exception?
Previous Comments:
[2012-09-04 06:01:05] ni...@php.net
By the way, in PHP 5.5 the behavior here changes and there is no warning at
all. The error will be available via json_last_error() and a second function
which returns a human readable string instead of an error code.
[2012-09-04 03:28:46] ras...@php.net
It isn't a new mechanism for PHP. We have had things like mysql_error(),
socket_last_error(), oci_error(), ldap_error(), pg_last_error(),
libxml_get_errors(), preg_last_error(), curl_error() and many money for a very
long time.
The main reason to not surface a warning here is that the only way to avoid it
would be to call iconv('utf-8','utf-8',$str) on all strings to be encoded. This
is a huge hassle to do, it is slow, and this is something we actually do
internally in json_encode() to validate utf-8 anyway, so it would be entirely
redundant. And since in many cases you end up passing user data or at least 3rd-
party data directly to json_encode() you would have to always add this
redundant
check.
[2012-09-04 03:17:44] david at grudl dot com
This is the only one function in whole PHP with this behaviour. So is it a new
way of error handling or bug?
[2012-09-03 23:36:20] ras...@php.net
json_encode() now checks for valid utf-8. It makes no sense to generate
warnings
for core functionality of the function. You can check json_last_error() for
JSON_ERROR_UTF8 if you want to programmatically catch invalid utf-8.
[2012-09-03 22:15:55] juzna dot cz at gmail dot com
Actually, a similar bug (52397) has been known for more than 2 years. In latest
snapshot of PHP 5.4 it just got worse :/
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63004
--
Edit this bug report at https://bugs.php.net/bug.php?id=63004&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1 ID: 63007 Comment by: janfili+phpbugs at gmail dot com Reported by:janfili+phpbugs at gmail dot com Summary:json functions corrupt arrayindizes Status: Not a bug Type: Bug Package:JSON related Operating System: Linux ubuntu1010 PHP Version:5.3.16 Block user comment: N Private report: N New Comment: not similar to https://bugs.php.net/bug.php?id=51915 51915 mentions that the indexes become strings, and that is the case of course through json en/decoding. The bug described in this ticket is that the elements belonging to these keys are not retrievable anymore. even if you explicitly get the keys $k = array_keys($array); echo $array[$k[0]]; will result in undefined index. Reductio ad absurdum Previous Comments: [2012-09-04 11:17:17] larue...@php.net similar to https://bugs.php.net/bug.php?id=51915 [2012-09-04 08:21:08] reeze dot xia at gmail dot com Yes, it will not accessible anymore if you have property with string number. since array handle keys different from objects. [2012-09-04 08:19:17] reeze dot xia at gmail dot com Ah, I'm sorry, the bug ID: #54082, I can't find the report right now. will post that later [2012-09-04 08:18:29] janfili+phpbugs at gmail dot com using this var_dump($array['1']); as the last statement will not help either [2012-09-04 08:04:22] reeze dot xia at gmail dot com This is not a problem of JSON itself. but. array vs object conversion. and it was documented: http://www.php.net/manual/en/language.types.array.php#language.types.array.casti ng after json_encode key: 1 was encoded as string. In object properties and only been string key. but after convert to array, it will not be able to accessed since. if the key will be changed to number key if possible. similar to https://bugs.php.net/bug.php?id=54082 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63007 -- Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #63007 [Opn->Nab]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1
ID: 63007
Updated by: larue...@php.net
Reported by:janfili+phpbugs at gmail dot com
Summary:json functions corrupt arrayindizes
-Status: Open
+Status: Not a bug
Type: Bug
Package:JSON related
Operating System: Linux ubuntu1010
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
similar to https://bugs.php.net/bug.php?id=51915
Previous Comments:
[2012-09-04 08:21:08] reeze dot xia at gmail dot com
Yes, it will not accessible anymore if you have property with string number.
since array handle keys different from objects.
[2012-09-04 08:19:17] reeze dot xia at gmail dot com
Ah, I'm sorry, the bug ID: #54082, I can't find the report right now.
will post that later
[2012-09-04 08:18:29] janfili+phpbugs at gmail dot com
using this var_dump($array['1']); as the last statement will not help either
[2012-09-04 08:04:22] reeze dot xia at gmail dot com
This is not a problem of JSON itself.
but. array vs object conversion. and it was documented:
http://www.php.net/manual/en/language.types.array.php#language.types.array.casti
ng
after json_encode key: 1 was encoded as string.
In object properties and only been string key.
but after convert to array, it will not be able to accessed since.
if the key will be changed to number key if possible.
similar to https://bugs.php.net/bug.php?id=54082
[2012-09-04 07:38:41] janfili+phpbugs at gmail dot com
Description:
after json en/decoding the original array index cant be used to retrieve the
values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Req #63008 [Opn]: Need reliable way of listing environment variables.
Edit report at https://bugs.php.net/bug.php?id=63008&edit=1
ID: 63008
User updated by:phpbugs at addiks dot de
Reported by:phpbugs at addiks dot de
Summary:Need reliable way of listing environment variables.
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Ubuntu/Debian
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
Problem with shell_exec is that it only works as long as program-execution is
allowed, so this can also not really be considered reliable. Some people
disable program-execution on productive servers for security reason, and prompt
them to allow program-execution just to read environment-vars does not sound
like the way to go.
Reading the environment-variables from phpinfo would be a possible way i have
not considered yet. That might work for now, but it sounds more like a dirty
workaround. I dont think that phpinfo() was designed to fetch the
environment-variables to your application on a regular basis. Who can guarantee
that there will always be a phpinfo providing env-var's and that the way it
does never change? (I dont like writing software with expiration-date.)
My opinion that there should be a 'listenv' like function to reliable list
environment-variables has not changed.
Previous Comments:
[2012-09-04 09:04:13] ras...@php.net
For your use-case it doesn't sound like performance is an issue so you could
just
do $env = shell_exec("env");
It is also technically available via phpinfo(INFO_ENVIRONMENT) although that
outputs it with html tags, so you would have to ob-parse it.
[2012-09-04 08:32:21] phpbugs at addiks dot de
There _would_ be also a third way of accessing environment-variables, accessing
'/proc/self/environ'. But that is not possible on most systems because when
using PHP as apache2-module the process gets spawned as root and setuid'd to
the apache-user, which leads to non-readable '/proc/self/*' files. Maybe there
can be something done in that direction?
[2012-09-04 08:17:46] phpbugs at addiks dot de
Description:
Hello there,
Currently there are only two ways of accessing environment-variables: a) Using
the getenv function, which allows you to access single previous known
environment variables, and b) using $_ENV, which is only filled when the
php.ini-directive 'variables_order' does contain an 'E', which is sometimes not
the case (on my machine that is default).
What i need is a method to list the environment variables no matter what
php.ini directives are set (unless access to environment-variables is not
explicit denied).
This is needed for things like error-handling for storing the state of the
environment to late better understand what is going on or environment-handling
in unit-testing. When you cannot list all environment variables, you can never
be sure that some variables will hide from you and ruin your testing.
Access (even write-access) to data which you cannot get a complete overview
from is just a crippled concept to me which needs to be fixed. Implementing
such a feature should not be too hard.
Test script:
---
0;");
return array_keys($_ENV);
}
foreach(listenv() as $key){
$value = var_export(getenv($key), true);
echo "\${$key} = {$value};\n";
}
Expected result:
$SHELL = '/bin/bash';
$TERM = 'xterm';
$USER = 'root';
$SUDO_USER = 'username';
$SUDO_UID = '1000';
$USERNAME = 'root';
$MAIL = '/var/mail/root';
$PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin';
$LC_MESSAGES = 'de_DE.UTF-8';
$LC_COLLATE = 'de_DE.UTF-8';
$PWD = '/home/username';
$LANG = 'de_DE.UTF-8';
$SHLVL = '1';
$SUDO_COMMAND = '/bin/su';
$HOME = '/root';
$LANGUAGE = 'de:en';
$LOGNAME = 'root';
$LC_CTYPE = 'de_DE.UTF-8';
$LESSOPEN = '| /usr/bin/lesspipe %s';
$SUDO_GID = '1003';
$DISPLAY = ':0';
$LESSCLOSE = '/usr/bin/lesspipe %s %s';
$XAUTHORITY = '/home/username/.Xauthority';
$COLORTERM = 'gnome-terminal';
$_ = '/usr/bin/php';
Actual result:
--
PHP Warning: assert(): Assertion "substr_count(ini_get('variables_order'),
'E')>0;" failed in /home/gerrit/test.php on line 10
PHP Stack trace:
PHP 1. {main}() /home/username/test.php:0
PHP 2. listenv() /home/username/test.php:14
PHP 3. assert('substr_count(ini_get(\'variables_order\'), \'E\')>0;')
/home/username/test.php:10
root@username:/home/username# php -r "var_dump(ini_get('variables_order'));"
string(4) "GPCS"
root@username:/home/username# # this is default-configuration.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63008&edit=1
Req #63008 [Opn]: Need reliable way of listing environment variables.
Edit report at https://bugs.php.net/bug.php?id=63008&edit=1
ID: 63008
Updated by: ras...@php.net
Reported by:phpbugs at addiks dot de
Summary:Need reliable way of listing environment variables.
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Ubuntu/Debian
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
For your use-case it doesn't sound like performance is an issue so you could
just
do $env = shell_exec("env");
It is also technically available via phpinfo(INFO_ENVIRONMENT) although that
outputs it with html tags, so you would have to ob-parse it.
Previous Comments:
[2012-09-04 08:32:21] phpbugs at addiks dot de
There _would_ be also a third way of accessing environment-variables, accessing
'/proc/self/environ'. But that is not possible on most systems because when
using PHP as apache2-module the process gets spawned as root and setuid'd to
the apache-user, which leads to non-readable '/proc/self/*' files. Maybe there
can be something done in that direction?
[2012-09-04 08:17:46] phpbugs at addiks dot de
Description:
Hello there,
Currently there are only two ways of accessing environment-variables: a) Using
the getenv function, which allows you to access single previous known
environment variables, and b) using $_ENV, which is only filled when the
php.ini-directive 'variables_order' does contain an 'E', which is sometimes not
the case (on my machine that is default).
What i need is a method to list the environment variables no matter what
php.ini directives are set (unless access to environment-variables is not
explicit denied).
This is needed for things like error-handling for storing the state of the
environment to late better understand what is going on or environment-handling
in unit-testing. When you cannot list all environment variables, you can never
be sure that some variables will hide from you and ruin your testing.
Access (even write-access) to data which you cannot get a complete overview
from is just a crippled concept to me which needs to be fixed. Implementing
such a feature should not be too hard.
Test script:
---
0;");
return array_keys($_ENV);
}
foreach(listenv() as $key){
$value = var_export(getenv($key), true);
echo "\${$key} = {$value};\n";
}
Expected result:
$SHELL = '/bin/bash';
$TERM = 'xterm';
$USER = 'root';
$SUDO_USER = 'username';
$SUDO_UID = '1000';
$USERNAME = 'root';
$MAIL = '/var/mail/root';
$PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin';
$LC_MESSAGES = 'de_DE.UTF-8';
$LC_COLLATE = 'de_DE.UTF-8';
$PWD = '/home/username';
$LANG = 'de_DE.UTF-8';
$SHLVL = '1';
$SUDO_COMMAND = '/bin/su';
$HOME = '/root';
$LANGUAGE = 'de:en';
$LOGNAME = 'root';
$LC_CTYPE = 'de_DE.UTF-8';
$LESSOPEN = '| /usr/bin/lesspipe %s';
$SUDO_GID = '1003';
$DISPLAY = ':0';
$LESSCLOSE = '/usr/bin/lesspipe %s %s';
$XAUTHORITY = '/home/username/.Xauthority';
$COLORTERM = 'gnome-terminal';
$_ = '/usr/bin/php';
Actual result:
--
PHP Warning: assert(): Assertion "substr_count(ini_get('variables_order'),
'E')>0;" failed in /home/gerrit/test.php on line 10
PHP Stack trace:
PHP 1. {main}() /home/username/test.php:0
PHP 2. listenv() /home/username/test.php:14
PHP 3. assert('substr_count(ini_get(\'variables_order\'), \'E\')>0;')
/home/username/test.php:10
root@username:/home/username# php -r "var_dump(ini_get('variables_order'));"
string(4) "GPCS"
root@username:/home/username# # this is default-configuration.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63008&edit=1
Req #63008 [Com]: Need reliable way of listing environment variables.
Edit report at https://bugs.php.net/bug.php?id=63008&edit=1
ID: 63008
Comment by: phpbugs at addiks dot de
Reported by:phpbugs at addiks dot de
Summary:Need reliable way of listing environment variables.
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Ubuntu/Debian
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
There _would_ be also a third way of accessing environment-variables, accessing
'/proc/self/environ'. But that is not possible on most systems because when
using PHP as apache2-module the process gets spawned as root and setuid'd to
the apache-user, which leads to non-readable '/proc/self/*' files. Maybe there
can be something done in that direction?
Previous Comments:
[2012-09-04 08:17:46] phpbugs at addiks dot de
Description:
Hello there,
Currently there are only two ways of accessing environment-variables: a) Using
the getenv function, which allows you to access single previous known
environment variables, and b) using $_ENV, which is only filled when the
php.ini-directive 'variables_order' does contain an 'E', which is sometimes not
the case (on my machine that is default).
What i need is a method to list the environment variables no matter what
php.ini directives are set (unless access to environment-variables is not
explicit denied).
This is needed for things like error-handling for storing the state of the
environment to late better understand what is going on or environment-handling
in unit-testing. When you cannot list all environment variables, you can never
be sure that some variables will hide from you and ruin your testing.
Access (even write-access) to data which you cannot get a complete overview
from is just a crippled concept to me which needs to be fixed. Implementing
such a feature should not be too hard.
Test script:
---
0;");
return array_keys($_ENV);
}
foreach(listenv() as $key){
$value = var_export(getenv($key), true);
echo "\${$key} = {$value};\n";
}
Expected result:
$SHELL = '/bin/bash';
$TERM = 'xterm';
$USER = 'root';
$SUDO_USER = 'username';
$SUDO_UID = '1000';
$USERNAME = 'root';
$MAIL = '/var/mail/root';
$PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin';
$LC_MESSAGES = 'de_DE.UTF-8';
$LC_COLLATE = 'de_DE.UTF-8';
$PWD = '/home/username';
$LANG = 'de_DE.UTF-8';
$SHLVL = '1';
$SUDO_COMMAND = '/bin/su';
$HOME = '/root';
$LANGUAGE = 'de:en';
$LOGNAME = 'root';
$LC_CTYPE = 'de_DE.UTF-8';
$LESSOPEN = '| /usr/bin/lesspipe %s';
$SUDO_GID = '1003';
$DISPLAY = ':0';
$LESSCLOSE = '/usr/bin/lesspipe %s %s';
$XAUTHORITY = '/home/username/.Xauthority';
$COLORTERM = 'gnome-terminal';
$_ = '/usr/bin/php';
Actual result:
--
PHP Warning: assert(): Assertion "substr_count(ini_get('variables_order'),
'E')>0;" failed in /home/gerrit/test.php on line 10
PHP Stack trace:
PHP 1. {main}() /home/username/test.php:0
PHP 2. listenv() /home/username/test.php:14
PHP 3. assert('substr_count(ini_get(\'variables_order\'), \'E\')>0;')
/home/username/test.php:10
root@username:/home/username# php -r "var_dump(ini_get('variables_order'));"
string(4) "GPCS"
root@username:/home/username# # this is default-configuration.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63008&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1
ID: 63007
Comment by: reeze dot xia at gmail dot com
Reported by:janfili+phpbugs at gmail dot com
Summary:json functions corrupt arrayindizes
Status: Open
Type: Bug
Package:JSON related
Operating System: Linux ubuntu1010
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
Yes, it will not accessible anymore if you have property with string number.
since array handle keys different from objects.
Previous Comments:
[2012-09-04 08:19:17] reeze dot xia at gmail dot com
Ah, I'm sorry, the bug ID: #54082, I can't find the report right now.
will post that later
[2012-09-04 08:18:29] janfili+phpbugs at gmail dot com
using this var_dump($array['1']); as the last statement will not help either
[2012-09-04 08:04:22] reeze dot xia at gmail dot com
This is not a problem of JSON itself.
but. array vs object conversion. and it was documented:
http://www.php.net/manual/en/language.types.array.php#language.types.array.casti
ng
after json_encode key: 1 was encoded as string.
In object properties and only been string key.
but after convert to array, it will not be able to accessed since.
if the key will be changed to number key if possible.
similar to https://bugs.php.net/bug.php?id=54082
[2012-09-04 07:38:41] janfili+phpbugs at gmail dot com
Description:
after json en/decoding the original array index cant be used to retrieve the
values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1
ID: 63007
Comment by: reeze dot xia at gmail dot com
Reported by:janfili+phpbugs at gmail dot com
Summary:json functions corrupt arrayindizes
Status: Open
Type: Bug
Package:JSON related
Operating System: Linux ubuntu1010
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
Ah, I'm sorry, the bug ID: #54082, I can't find the report right now.
will post that later
Previous Comments:
[2012-09-04 08:18:29] janfili+phpbugs at gmail dot com
using this var_dump($array['1']); as the last statement will not help either
[2012-09-04 08:04:22] reeze dot xia at gmail dot com
This is not a problem of JSON itself.
but. array vs object conversion. and it was documented:
http://www.php.net/manual/en/language.types.array.php#language.types.array.casti
ng
after json_encode key: 1 was encoded as string.
In object properties and only been string key.
but after convert to array, it will not be able to accessed since.
if the key will be changed to number key if possible.
similar to https://bugs.php.net/bug.php?id=54082
[2012-09-04 07:38:41] janfili+phpbugs at gmail dot com
Description:
after json en/decoding the original array index cant be used to retrieve the
values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1
ID: 63007
Comment by: janfili+phpbugs at gmail dot com
Reported by:janfili+phpbugs at gmail dot com
Summary:json functions corrupt arrayindizes
Status: Open
Type: Bug
Package:JSON related
Operating System: Linux ubuntu1010
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
using this var_dump($array['1']); as the last statement will not help either
Previous Comments:
[2012-09-04 08:04:22] reeze dot xia at gmail dot com
This is not a problem of JSON itself.
but. array vs object conversion. and it was documented:
http://www.php.net/manual/en/language.types.array.php#language.types.array.casti
ng
after json_encode key: 1 was encoded as string.
In object properties and only been string key.
but after convert to array, it will not be able to accessed since.
if the key will be changed to number key if possible.
similar to https://bugs.php.net/bug.php?id=54082
[2012-09-04 07:38:41] janfili+phpbugs at gmail dot com
Description:
after json en/decoding the original array index cant be used to retrieve the
values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
[PHP-BUG] Req #63008 [NEW]: Need reliable way of listing environment variables.
From: phpbugs at addiks dot de
Operating system: Ubuntu/Debian
PHP version: 5.4.6
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Need reliable way of listing environment variables.
Description:
Hello there,
Currently there are only two ways of accessing environment-variables: a)
Using the getenv function, which allows you to access single previous known
environment variables, and b) using $_ENV, which is only filled when the
php.ini-directive 'variables_order' does contain an 'E', which is sometimes
not the case (on my machine that is default).
What i need is a method to list the environment variables no matter what
php.ini directives are set (unless access to environment-variables is not
explicit denied).
This is needed for things like error-handling for storing the state of the
environment to late better understand what is going on or
environment-handling in unit-testing. When you cannot list all environment
variables, you can never be sure that some variables will hide from you and
ruin your testing.
Access (even write-access) to data which you cannot get a complete overview
from is just a crippled concept to me which needs to be fixed. Implementing
such a feature should not be too hard.
Test script:
---
0;");
return array_keys($_ENV);
}
foreach(listenv() as $key){
$value = var_export(getenv($key), true);
echo "\${$key} = {$value};\n";
}
Expected result:
$SHELL = '/bin/bash';
$TERM = 'xterm';
$USER = 'root';
$SUDO_USER = 'username';
$SUDO_UID = '1000';
$USERNAME = 'root';
$MAIL = '/var/mail/root';
$PATH = '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin';
$LC_MESSAGES = 'de_DE.UTF-8';
$LC_COLLATE = 'de_DE.UTF-8';
$PWD = '/home/username';
$LANG = 'de_DE.UTF-8';
$SHLVL = '1';
$SUDO_COMMAND = '/bin/su';
$HOME = '/root';
$LANGUAGE = 'de:en';
$LOGNAME = 'root';
$LC_CTYPE = 'de_DE.UTF-8';
$LESSOPEN = '| /usr/bin/lesspipe %s';
$SUDO_GID = '1003';
$DISPLAY = ':0';
$LESSCLOSE = '/usr/bin/lesspipe %s %s';
$XAUTHORITY = '/home/username/.Xauthority';
$COLORTERM = 'gnome-terminal';
$_ = '/usr/bin/php';
Actual result:
--
PHP Warning: assert(): Assertion "substr_count(ini_get('variables_order'),
'E')>0;" failed in /home/gerrit/test.php on line 10
PHP Stack trace:
PHP 1. {main}() /home/username/test.php:0
PHP 2. listenv() /home/username/test.php:14
PHP 3. assert('substr_count(ini_get(\'variables_order\'), \'E\')>0;')
/home/username/test.php:10
root@username:/home/username# php -r
"var_dump(ini_get('variables_order'));"
string(4) "GPCS"
root@username:/home/username# # this is default-configuration.
--
Edit bug report at https://bugs.php.net/bug.php?id=63008&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63008&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63008&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63008&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63008&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=63008&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63008&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=63008&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=63008&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=63008&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=63008&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=63008&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63008&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63008&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63008&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=63008&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63008&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=63008&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=63008&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=63008&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=63008&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=63008&r=mysqlcfg
Bug #62907 [PATCH]: Double free when use traits
Edit report at https://bugs.php.net/bug.php?id=62907&edit=1 ID: 62907 Patch added by: dmi...@php.net Reported by:larue...@php.net Summary:Double free when use traits Status: Assigned Type: Bug Package:Scripting Engine problem PHP Version:5.4.6 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: alias.diff Revision: 1346746351 URL: https://bugs.php.net/patch-display.php?bug=62907&patch=alias.diff&revision=1346746351 Previous Comments: [2012-08-26 10:33:08] larue...@php.net Unless we re-implement the whole alias thing, drop the tricky. we could not fix this properly, even we can do some works in the abstrct methods copy, but it still in a wrong way. Dmitry, could you please look at this? thanks [2012-08-23 15:32:28] larue...@php.net assign to my self. [2012-08-23 15:31:43] larue...@php.net Description: This bug is related to #61998, but was spotting when I fixing the bug #62358, PS: it really tough to refine this reproduce script :) Test script: --- https://bugs.php.net/bug.php?id=62907&edit=1
Bug #63007 [Com]: json functions corrupt arrayindizes
Edit report at https://bugs.php.net/bug.php?id=63007&edit=1
ID: 63007
Comment by: reeze dot xia at gmail dot com
Reported by:janfili+phpbugs at gmail dot com
Summary:json functions corrupt arrayindizes
Status: Open
Type: Bug
Package:JSON related
Operating System: Linux ubuntu1010
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
This is not a problem of JSON itself.
but. array vs object conversion. and it was documented:
http://www.php.net/manual/en/language.types.array.php#language.types.array.casti
ng
after json_encode key: 1 was encoded as string.
In object properties and only been string key.
but after convert to array, it will not be able to accessed since.
if the key will be changed to number key if possible.
similar to https://bugs.php.net/bug.php?id=54082
Previous Comments:
[2012-09-04 07:38:41] janfili+phpbugs at gmail dot com
Description:
after json en/decoding the original array index cant be used to retrieve the
values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit this bug report at https://bugs.php.net/bug.php?id=63007&edit=1
[PHP-BUG] Bug #63007 [NEW]: json functions corrupt arrayindizes
From: janfili+phpbugs at gmail dot com
Operating system: Linux ubuntu1010
PHP version: 5.3.16
Package: JSON related
Bug Type: Bug
Bug description:json functions corrupt arrayindizes
Description:
after json en/decoding the original array index cant be used to retrieve
the values.
however foreach and all other array-related functions work as expected.
Test script:
---
field = 'foo';
var_dump($class);
$array = array(1 => $class);
var_dump($array);
$json_sting = json_encode($array);
var_dump($json_sting);
$array_obj = json_decode($json_sting);
var_dump($array_obj);
$array = (array) $array_obj;
var_dump($array);
var_dump($array[1]);
?>
Expected result:
output of last var_dump is expected to be
object(stdClass)#3 (1) {
["field"]=>
string(3) "foo"
}
Actual result:
--
NULL
--
Edit bug report at https://bugs.php.net/bug.php?id=63007&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63007&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63007&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63007&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63007&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=63007&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63007&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=63007&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=63007&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=63007&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=63007&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=63007&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63007&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63007&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63007&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=63007&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63007&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=63007&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=63007&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=63007&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=63007&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=63007&r=mysqlcfg
[PHP-BUG] Req #63006 [NEW]: call just defined anonymous function
From: printercu at gmail dot com
Operating system: any
PHP version: 5.4Git-2012-09-04 (Git)
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:call just defined anonymous function
Description:
It would be useful to call just defined anonymous function to get private
variable scope like this:
$bar = 1;
...
$foo = (function()
{
$bar = [1, 2, 3];
$bar[ 'sum' ] = array_sum( $bar );
return $bar;
})();
# $bar is unchanged
--
Edit bug report at https://bugs.php.net/bug.php?id=63006&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63006&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63006&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63006&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=63006&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=63006&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=63006&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=63006&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=63006&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=63006&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=63006&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=63006&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63006&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63006&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=63006&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=63006&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=63006&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=63006&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=63006&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=63006&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=63006&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=63006&r=mysqlcfg
Bug #62991 [Asn]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Updated by: larue...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. Status: Assigned Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: the static variable table should also be copied, and this func will be copied once / per closure called (create a new genartor). maybe add a new ACC flag is much more simple... which we have discussed before( I also discussed that with nikic :)) Previous Comments: [2012-09-04 06:57:58] dmi...@php.net I've added a much simpler patch. Please take a look. [2012-09-02 11:50:39] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.phpt Revision: 1346586639 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.phpt&revision=1346586639 [2012-09-02 11:46:56] larue...@php.net a new patch has been attached, fixed the memleak issue, but the way is a little tricky, used the op_array->reserved fields. so I attached it here instead of ci it, wait for if we can find a better way [2012-09-02 11:45:06] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346586306 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346586306 [2012-09-02 11:24:00] larue...@php.net okey, but is there a way to find out that whether a generator has been run once? leaks reporting if the closure didn't run. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62991 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
