Bug #64046 [Com]: Segmentation fault in pcre library
Edit report at https://bugs.php.net/bug.php?id=64046&edit=1 ID: 64046 Comment by: php at richardneill dot org Reported by:public at miholeus dot com Summary:Segmentation fault in pcre library Status: Not a bug Type: Bug Package:PCRE related Operating System: Ubuntu 12.04.1 LTS PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I've just been bitten by this bug too. It manifests as "Connection Reset" error on the website, and this in the apache logs: "[Sun Jun 30 20:58:07 2013] [notice] child pid 32544 exit signal Segmentation fault (11)" I do understand that the segfault isn't a PHP bug, but it would be really helpful if the error message could be more specific: something like "segfault in PCRE at line X in file Y". Aside: another test-case. Here, it can be triggered by a value over about 5400: $input=''.str_repeat('X', 5500).''; $output = preg_replace("/(((?!(<\/span>)).)*)<\/span>/", "BEGIN \\1 END" ,$input); If I reduce pcre.recursion_limit converts the segfault into a PCRE failure... but there is nothing that will make the RE actually work as intended. (in the contrived example, we can of course just use str_replace). Previous Comments: [2013-01-24 15:28:45] public at miholeus dot com I understand. Thanks for reply. [2013-01-24 08:35:09] paj...@php.net Not a PHP bug but pcre recursion classic stack crash, see the numerous other reports for more info. [2013-01-23 18:12:19] krak...@php.net This does cause a stack overflow, for some reason the default limits for recursion are very high, maybe someone has an explanation of that. You have: "/'([^'])*'/" Shouldn't that be: "/'([^']*)'/" ? [2013-01-22 13:47:19] public at miholeus dot com Description: The following code causes segmentation fault. You can see the code by link I've provided. Test script: --- Code http://pastebin.com/UzBjDaZU Expected result: no segfault Actual result: -- With gdb: (gdb) run /var/www/work/crm/trunk/pcre.php Starting program: /usr/bin/php /var/www/work/crm/trunk/pcre.php [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe42e4700 (LWP 4329)] [Thread 0x7fffe42e4700 (LWP 4329) exited] Program received signal SIGSEGV, Segmentation fault. 0x76d99a62 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3 -- Edit this bug report at https://bugs.php.net/bug.php?id=64046&edit=1
Bug #64518 [Nab]: optimisation for "for ($i=0; $i
Edit report at https://bugs.php.net/bug.php?id=64518&edit=1 ID: 64518 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:optimisation for "for ($i=0; $ihttp://www.richardneill.org/tmp/php-perf.txt I notice 3 things. 1) Updating a variable in-place is 1000x slower than creating a new one. Fast: $n = count($data); Slow:$data = count($data); 2) Using $GLOBALS['var'] inside a function is very similar to using the same variable in the main scope. Using "global $var" is always at least a bit slower. 3) Using global for just reading a variable is 100x slower than reading it from $GLOBALS inside a function. Fast: $n = count($GLOBALS['data']) Slow: global $data; $n = count ($data) I think that (3) might be a bug. I also think that these differences are far from negligible, and so PHP's documentation *should* mention them. Previous Comments: [2013-03-26 15:57:08] ni...@php.net It's not always faster. Which one is faster is not very predictable without good knowledge of the engine. We don't address such low-level details in the manual. ---------------- [2013-03-26 15:15:38] php at richardneill dot org > The issue you are seeing is that `global $data` is a by-reference fetch > (unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass > prevents us from doing a copy-on-write optimization when passing the array to > the by-value count() function, so the array has to be copied every single > time. Thanks for the explanation. That makes some sense as an explanation. However, it also implies that use of "$GLOBALS['var']" is always faster, sometimes much faster, than "global $var". If this is true, might I suggest that this is a documentation issue that should be addressed? [2013-03-26 13:34:40] ni...@php.net The issue you are seeing is that `global $data` is a by-reference fetch (unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass prevents us from doing a copy-on-write optimization when passing the array to the by-value count() function, so the array has to be copied every single time. The specific count() case is something we could optimize by adding a read-only passing mode for function arguments (that never separates zvals). As that is something that's also useful for a few other things, it might well be worth doing. [2013-03-26 06:34:44] php at richardneill dot org ... and getting closer to the source of the problem... function a(){ //about 1400 us global $data; $n = $data; } function b(){ //much much quicker: about 18us $n = $GLOBALS['data']; } Something is definitely wrong here, that makes "global" so much slower than $GLOBALS. Also, this isn't a read-only optimisation which makes b() much quicker than a(); it still applies even when we want to copy back into the global scope. Consider: function x(){ $n = $GLOBALS['data']; $GLOBALS['data'] = count($n); } and x() is always about as fast as b(). A secondary problem: if x() is rewritten as: function y(){ $GLOBALS['data'] = count($GLOBALS['data']); } then it can be either fast or slow depending on whether other function calls contain "global $data" or not. [2013-03-26 06:09:30] php at richardneill dot org Here's a simpler test case. The problem is actually that accessing global variables from functions is much slower than local variables (and I was seeing this exacerbated by looping over them with count). Note that passing the data directly as a function argument is much faster than passing it as a global variable - this seems to me to be the root of the problem. i.e. function ($a,$b,$c,$large_array){ //do stuff - this is fast. } function ($a,$b,$c){ global $large_array //do stuff - this is SLOW. } #!/usr/bin/php -ddisplay_errors=E_ALL 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=64518 -- Edit this bug report at https://bugs.php.net/bug.php?id=64518&edit=1
Bug #64518 [Nab]: optimisation for "for ($i=0; $i
Edit report at https://bugs.php.net/bug.php?id=64518&edit=1 ID: 64518 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:optimisation for "for ($i=0; $i The issue you are seeing is that `global $data` is a by-reference fetch > (unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass > prevents us from doing a copy-on-write optimization when passing the array to > the by-value count() function, so the array has to be copied every single > time. Thanks for the explanation. That makes some sense as an explanation. However, it also implies that use of "$GLOBALS['var']" is always faster, sometimes much faster, than "global $var". If this is true, might I suggest that this is a documentation issue that should be addressed? Previous Comments: [2013-03-26 13:34:40] ni...@php.net The issue you are seeing is that `global $data` is a by-reference fetch (unlike `$data = $GLOBALS['data']`, which is by-value). The by-ref pass prevents us from doing a copy-on-write optimization when passing the array to the by-value count() function, so the array has to be copied every single time. The specific count() case is something we could optimize by adding a read-only passing mode for function arguments (that never separates zvals). As that is something that's also useful for a few other things, it might well be worth doing. -------------------- [2013-03-26 06:34:44] php at richardneill dot org ... and getting closer to the source of the problem... function a(){ //about 1400 us global $data; $n = $data; } function b(){ //much much quicker: about 18us $n = $GLOBALS['data']; } Something is definitely wrong here, that makes "global" so much slower than $GLOBALS. Also, this isn't a read-only optimisation which makes b() much quicker than a(); it still applies even when we want to copy back into the global scope. Consider: function x(){ $n = $GLOBALS['data']; $GLOBALS['data'] = count($n); } and x() is always about as fast as b(). A secondary problem: if x() is rewritten as: function y(){ $GLOBALS['data'] = count($GLOBALS['data']); } then it can be either fast or slow depending on whether other function calls contain "global $data" or not. [2013-03-26 06:09:30] php at richardneill dot org Here's a simpler test case. The problem is actually that accessing global variables from functions is much slower than local variables (and I was seeing this exacerbated by looping over them with count). Note that passing the data directly as a function argument is much faster than passing it as a global variable - this seems to me to be the root of the problem. i.e. function ($a,$b,$c,$large_array){ //do stuff - this is fast. } function ($a,$b,$c){ global $large_array //do stuff - this is SLOW. } -------- #!/usr/bin/php -ddisplay_errors=E_ALL [2013-03-26 05:17:44] php at richardneill dot org Description: If an array is counted inside a for-loop, this is normally slightly inefficient. $n = count ($array); //[1] optimised and a bit faster. for ($i=0; $i< $n;$i++){ //do stuff } for ($i=0; $i Expected result: All 4 ways of summing this array should run in similar amounts of time (a few milliseconds). But actually add_slow() is 3900 times slower. Actual result: -- This demonstrates the problem with counting global arrays inside loops inside functions. Calling add_slow()... Total (slow) is 49995000. Finished in 7.86 seconds. Calling add_fast()... Total (fast) is 49995000. Finished in 0.002 seconds. Calling add_local()... Total (local) is 49995000. Finished in 0.006 seconds. Not using a function... Total (main loop) is 49995000. Finished in 0.002 seconds. -- Edit this bug report at https://bugs.php.net/bug.php?id=64518&edit=1
Bug #64518 [Com]: optimisation for "for ($i=0; $i
Edit report at https://bugs.php.net/bug.php?id=64518&edit=1 ID: 64518 Comment by: php at richardneill dot org Reported by: php at richardneill dot org Summary:optimisation for "for ($i=0; $i [2013-03-26 05:17:44] php at richardneill dot org Description: If an array is counted inside a for-loop, this is normally slightly inefficient. $n = count ($array); //[1] optimised and a bit faster. for ($i=0; $i< $n;$i++){ //do stuff } for ($i=0; $i Expected result: All 4 ways of summing this array should run in similar amounts of time (a few milliseconds). But actually add_slow() is 3900 times slower. Actual result: -- This demonstrates the problem with counting global arrays inside loops inside functions. Calling add_slow()... Total (slow) is 49995000. Finished in 7.86 seconds. Calling add_fast()... Total (fast) is 49995000. Finished in 0.002 seconds. Calling add_local()... Total (local) is 49995000. Finished in 0.006 seconds. Not using a function... Total (main loop) is 49995000. Finished in 0.002 seconds. -- Edit this bug report at https://bugs.php.net/bug.php?id=64518&edit=1
Bug #64518 [Com]: optimisation for "for ($i=0; $i
Edit report at https://bugs.php.net/bug.php?id=64518&edit=1 ID: 64518 Comment by: php at richardneill dot org Reported by: php at richardneill dot org Summary:optimisation for "for ($i=0; $i Previous Comments: [2013-03-26 05:17:44] php at richardneill dot org Description: If an array is counted inside a for-loop, this is normally slightly inefficient. $n = count ($array); //[1] optimised and a bit faster. for ($i=0; $i< $n;$i++){ //do stuff } for ($i=0; $i Expected result: All 4 ways of summing this array should run in similar amounts of time (a few milliseconds). But actually add_slow() is 3900 times slower. Actual result: -- This demonstrates the problem with counting global arrays inside loops inside functions. Calling add_slow()... Total (slow) is 49995000. Finished in 7.86 seconds. Calling add_fast()... Total (fast) is 49995000. Finished in 0.002 seconds. Calling add_local()... Total (local) is 49995000. Finished in 0.006 seconds. Not using a function... Total (main loop) is 49995000. Finished in 0.002 seconds. -- Edit this bug report at https://bugs.php.net/bug.php?id=64518&edit=1
[PHP-BUG] Bug #64518 [NEW]: optimisation for "for ($i=0; $i
From: php at richardneill dot org Operating system: PHP version: 5.4.13 Package: Performance problem Bug Type: Bug Bug description:optimisation for "for ($i=0; $i Expected result: All 4 ways of summing this array should run in similar amounts of time (a few milliseconds). But actually add_slow() is 3900 times slower. Actual result: -- This demonstrates the problem with counting global arrays inside loops inside functions. Calling add_slow()... Total (slow) is 49995000. Finished in 7.86 seconds. Calling add_fast()... Total (fast) is 49995000. Finished in 0.002 seconds. Calling add_local()... Total (local) is 49995000. Finished in 0.006 seconds. Not using a function... Total (main loop) is 49995000. Finished in 0.002 seconds. -- Edit bug report at https://bugs.php.net/bug.php?id=64518&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64518&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64518&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64518&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64518&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64518&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64518&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64518&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64518&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64518&r=support Expected behavior: https://bugs.php.net/fix.php?id=64518&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64518&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64518&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64518&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64518&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64518&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64518&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64518&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64518&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64518&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64518&r=mysqlcfg
[PHP-BUG] Req #64516 [NEW]: wish: add flag to preg_quote to escape the replacement
From: php at richardneill dot org Operating system: all PHP version: 5.4.13 Package: PCRE related Bug Type: Feature/Change Request Bug description:wish: add flag to preg_quote to escape the replacement Description: preg_quote() is great for escaping a user-supplied search string. There is no matching function to escape a user-supplied replacement string. My wish is for preg_quote() to have an extra flag "IS_REPLACEMENT" or to have a function preg_quote_replacement(), which would escape only backslash and dollar signs. Example below. Might I also suggest this is a documentation bug, in that there is no explanation of the correct way to work around this? Test script: --- $text = 'Invoice: You owe me *#5* !'; $user_search = "*#5*"; $user_replace = "*$5*"; $search = preg_quote($user_search, "/"); $replace_bad1 = $user_replace; $replace_bad2 = preg_quote($user_replace); $new_text1 = preg_replace("/$search/", "$replace_bad1", $text); $new_text2 = preg_replace("/$search/", "$replace_bad2", $text); echo "Input: $text\nNew1: $new_text1\nNew2: $new_text2\n"; Expected result: I want to return the string: Invoice: You owe me *$5* ! Actual result: -- Input: Invoice: You owe me *#5* ! New1: Invoice: You owe me ** ! New2: Invoice: You owe me \*$5\* ! 1. the '*' in the search string is not magic, thanks to the normal use of preg_quote(). This is what I expect. 2. If I replace with a literal, then '$5' becomes the 5th backreference, which is empty. 3. If I preg_quote the replacement, then we get spurious backslashes before the '*'s. -- Edit bug report at https://bugs.php.net/bug.php?id=64516&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64516&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64516&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64516&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64516&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64516&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64516&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64516&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64516&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64516&r=support Expected behavior: https://bugs.php.net/fix.php?id=64516&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64516&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64516&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64516&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64516&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64516&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64516&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64516&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64516&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64516&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64516&r=mysqlcfg
[PHP-BUG] Req #64488 [NEW]: Allow open tag to "discard the previous shebang"
From: php at richardneill dot org Operating system: PHP version: 5.4.13 Package: CGI/CLI related Bug Type: Feature/Change Request Bug description:Allow open tag to "discard the previous shebang" Description: It would be really useful to be able to write single files that would run cleanly as *either* CGI or CLI scripts. At the moment, the closing '?>' tag will eat the trailing newline. So, similarly, I'd like to request a way for the opening '"; }else{ echo "I am CLI\n"; } ?> Expected result: Exactly one line should be printed: "I am CLI|CGI" Actual result: -- In CLI mode, this script cleanly prints: "I am CLI" but in Apache mode, the script prints the first line literally: "#!/usr/bin/php I am CGI" It's relatively easy to work around this with a wrapper script, but I'd appreciate the elegance of having a single file that can operate in both modes. Thank you for your time. -- Edit bug report at https://bugs.php.net/bug.php?id=64488&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64488&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64488&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64488&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64488&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64488&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64488&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64488&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64488&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64488&r=support Expected behavior: https://bugs.php.net/fix.php?id=64488&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64488&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64488&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64488&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64488&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64488&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64488&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64488&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64488&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64488&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64488&r=mysqlcfg
Req #64320 [Fbk->Csd]: Proposal: deprecate the "leading 0 means octal" behaviour
Edit report at https://bugs.php.net/bug.php?id=64320&edit=1 ID: 64320 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:Proposal: deprecate the "leading 0 means octal" behaviour -Status: Feedback +Status: Closed Type: Feature/Change Request Package:Math related Operating System: All PHP Version:5.4.12 Block user comment: N Private report: N New Comment: You know, that bug has annoyed me for ages, since I got badly bitten by it about 7 years ago. In the meantime, I think it's been fixed! At any rate, I now agree with you that the current behaviour is correct, and that: PHP now treats strings with leading zeros (eg "0123") as decimal (123), rather than octal, even when automatically casting them. The documentation (in the sections: integers, casting) could perhaps be more explicit, given that: $a = 0x123; $b = "0x123" + 0; // $a and $b are equal $c = 0123; $d = "0123" + 0; // $c and $d are not equal. Sorry for the confusion - my bad. Previous Comments: [2013-02-28 17:14:36] ni...@php.net Could you maybe provide a testcase for the behavior you are referring to? I tried out the following and "010" wasn't interpreted as octal in any case: var_dump((int) "010", intval("010"), "010" == 8); // Outputs: int(10) int(10) bool(false) 010 is only treated as an octal if you write it out plainly (in the source code), like $foo = 010; ---------------- [2013-02-28 13:41:48] php at richardneill dot org Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean "this is an octal number". This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example "$x = 0100"). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = "0.314" //user-submitted data, known to begin "0." $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = "0.031", this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit this bug report at https://bugs.php.net/bug.php?id=64320&edit=1
[PHP-BUG] Req #64320 [NEW]: Proposal: deprecate the "leading 0 means octal" behaviour
From: php at richardneill dot org Operating system: All PHP version: 5.4.12 Package: Math related Bug Type: Feature/Change Request Bug description:Proposal: deprecate the "leading 0 means octal" behaviour Description: PHP assumes that a string with a leading zero should be interpreted as octal. In my experience, this is almost never useful, desirable, or intentional, however, it is a frequent trap for the beginner (or more experienced programmer), especially when parsing user-submitted data. The only reason for this behaviour seems to be historical, and compatibility with strtol(). When non-programmer humans write numbers with leading zeros, they don't usually mean base 8. My proposal is: 1. Introduce a new string format, 0o (letter o), to explicitly mean "this is an octal number". This is similar to the recent introduction of 0b for binary numbers. [This part should be simple to do, and would also make the intentional use of octal notation explicit, increasing code-readability] 2. Add an option to raise E_NOTICE any time a number is implicitly interpreted as octal (for example "$x = 0100"). 3. In a few years time, (PHP 7?), it may finally be possible to change the default behaviour. Test script: --- Here's an illustration of a naive program that has data-dependent bugs that are really hard to track down. $mass_kg = "0.314" //user-submitted data, known to begin "0." $mass_g = substr ($mass_kg, 2); Yes, this is a silly thing to write. But it's a nasty trap for the unwary. The above example does what is expected, and might pass many tests. But if the user subsequently enters $mass_kg = "0.031", this will turn into 25 grams, not 31 grams. As a result, we have created a very subtle and hard to find bug. -- Edit bug report at https://bugs.php.net/bug.php?id=64320&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64320&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64320&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64320&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64320&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64320&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64320&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64320&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64320&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64320&r=support Expected behavior: https://bugs.php.net/fix.php?id=64320&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64320&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64320&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64320&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64320&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64320&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64320&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64320&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64320&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64320&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64320&r=mysqlcfg
[PHP-BUG] Bug #62998 [NEW]: pg_query_params() doesn't handle NULL
From: php at richardneill dot org Operating system: Linux PHP version: 5.3.16 Package: PostgreSQL related Bug Type: Bug Bug description:pg_query_params() doesn't handle NULL Description: pg_query_params($conn,$sql,$params) is supposed to correctly handle NULL->SQL_NULL. It doesn't do this (despite the documentation); instead it breaks the query. Documentation "If parameters are used, they are referred to in the query string as $1, $2, etc. params specifies the actual values of the parameters. A NULL value in this array means the corresponding parameter is SQL NULL. " Test script: --- Here's a simple example: $result = pg_query_params ($conn, "select CASE WHEN NULL is $1 then 'it is null' ELSE 'it is not null' END", array(NULL) ); echo pg_last_error($conn); print_r (pg_fetch_assoc($result)); This query fails, because the parameter $1 is not actually passed as NULL, instead it seems to be the empty string. My SQL is definitely right: pg_query_params ($conn, "select CASE WHEN NULL is NULL then 'it is null' ELSE 'it is not null' END", array() ); works fine, to return the string "it is null". Expected result: It should be possible to pass SQL_NULL to the database in a parameter. -- Edit bug report at https://bugs.php.net/bug.php?id=62998&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62998&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62998&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62998&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62998&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62998&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62998&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62998&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62998&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62998&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62998&r=support Expected behavior: https://bugs.php.net/fix.php?id=62998&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62998&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62998&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62998&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62998&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62998&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62998&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62998&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62998&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62998&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62998&r=mysqlcfg
Bug #43627 [Com]: fopen blocks on fifo
Edit report at https://bugs.php.net/bug.php?id=43627&edit=1 ID: 43627 Comment by: php at richardneill dot org Reported by:user at example dot com Summary:fopen blocks on fifo Status: Bogus Type: Bug Package:Filesystem function related Operating System: Debian Etch and RHEL 5 PHP Version:5.2.5 Block user comment: N Private report: N New Comment: Similarly, fopen blocks if the fifo is opened for writing, and the "other side" isn't being read yet: $fp = fopen('myfifo', 'w'); I'd expect the fwrite() to block, but not the fopen(). Linux's man fifo says that this is the default behaviour, but that it is possible to make it non-blocking. This would be useful, because we can't call stream_select() to find out whether writes would block until we have fopen()'d the pipe, but fopen() blocks. There is no way to test in advance whether fopen() would block, because most cases don't expect it to. Previous Comments: [2008-01-29 00:15:50] tony2...@php.net man open man 7 fifo "Normally, opening the FIFO blocks until the other end is opened also." [2007-12-18 16:59:10] user at example dot com Description: fopen() blocks waiting for read on named pipes (FIFOs) opened for reading. Reproduce code: --- At Unix prompt: % mkfifo myfifo PHP: $fp = fopen('myfifo', 'r'); Expected result: PHP execution should continue until attempting to read from the FIFO, e.g.: fread($fp, 1); Actual result: -- PHP execution suspends (blocks) on the fopen() command until another process writes data to the FIFO. -- Edit this bug report at https://bugs.php.net/bug.php?id=43627&edit=1
Bug #54614 [Fbk->Opn]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614&edit=1 ID: 54614 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:Trivial RE failure: /([^b]*a*)*$/ -Status: Feedback +Status: Open Type: Bug Package:*Regular Expressions Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry, my bad (sort of). There is a genuine bug that affected longer regexps even with backtrack.limit set to 32M, which I saw on 5.3.2, but is now solved on 5.3.6. Unfortunately, the test-case which I simplified for the bug-report didn't remember to set backtrack.limit (I thought I'd done it in php.ini, but had actually done it explicitly with ini.set in my original script). So the test case: - works for backtrack.limit = 1M (on both 5.3.2 and 5.3.6) - fails for the default 100k on both. Either way, it's still something that, imho, should work on a default install. May I make a few suggestions: * backtrack.limit should be raised by default, to at least 10M. * backtrack.limit should default to 100M for the CLI version of PHP. * validating bug reports is painful, partly because I had to spend some extra time tracking down the latest version of PHP and building it. This is error- prone. How about providing a sandboxed VM on bugs.php.net where we can paste our own code to check it? This would make it far easier to file correct bug reports. (it would take the reporter 3 minutes, rather than an hour). Previous Comments: [2011-04-27 21:54:07] ras...@php.net With pcre.backtrack_limit = 100 this works fine for me on 5.3.6. Are you sure you increased the limit in the right place? [2011-04-27 21:15:34] php at richardneill dot org A slightly simpler test case is: $contents = "b"; $search = '/(a*a*)*$/'; -------- [2011-04-27 18:43:02] php at richardneill dot org Description: If I search in the string : 'b' with the RE: '/([^b]*a*)*$/' then preg_replace fails with a backtrack-limit error. (error 2) I have backtrack.limit configured to 32MB, so something is very wrong. The example fails on several different PHP versions, CPU architectures and Linux Distros. However, using Perl for the same RE works fine. Test script: --- $contents = "b"; $search = '/([^b]*a*)*$/'; $result = preg_replace($search,"x",$contents); if ($result === NULL){ echo "preg failed, error is ".preg_last_error()."\n"; }else{ echo "success\n"; } Expected result: preg_replace shouldn't fail. Actual result: -- preg_replace returns NULL, and preg_last_error returns 2. -- Edit this bug report at http://bugs.php.net/bug.php?id=54614&edit=1
Bug #54614 [Opn]: Trivial RE failure: /([^b]*a*)*$/
Edit report at http://bugs.php.net/bug.php?id=54614&edit=1 ID: 54614 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:Trivial RE failure: /([^b]*a*)*$/ Status: Open Type: Bug Package:*Regular Expressions Operating System: Linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: A slightly simpler test case is: $contents = "b"; $search = '/(a*a*)*$/'; Previous Comments: ---- [2011-04-27 18:43:02] php at richardneill dot org Description: If I search in the string : 'b' with the RE: '/([^b]*a*)*$/' then preg_replace fails with a backtrack-limit error. (error 2) I have backtrack.limit configured to 32MB, so something is very wrong. The example fails on several different PHP versions, CPU architectures and Linux Distros. However, using Perl for the same RE works fine. Test script: --- $contents = "b"; $search = '/([^b]*a*)*$/'; $result = preg_replace($search,"x",$contents); if ($result === NULL){ echo "preg failed, error is ".preg_last_error()."\n"; }else{ echo "success\n"; } Expected result: preg_replace shouldn't fail. Actual result: -- preg_replace returns NULL, and preg_last_error returns 2. -- Edit this bug report at http://bugs.php.net/bug.php?id=54614&edit=1
[PHP-BUG] Bug #54614 [NEW]: Trivial RE failure: /([^b]*a*)*$/
From: Operating system: Linux PHP version: 5.3.6 Package: *Regular Expressions Bug Type: Bug Bug description:Trivial RE failure: /([^b]*a*)*$/ Description: If I search in the string : 'b' with the RE: '/([^b]*a*)*$/' then preg_replace fails with a backtrack-limit error. (error 2) I have backtrack.limit configured to 32MB, so something is very wrong. The example fails on several different PHP versions, CPU architectures and Linux Distros. However, using Perl for the same RE works fine. Test script: --- $contents = "b"; $search = '/([^b]*a*)*$/'; $result = preg_replace($search,"x",$contents); if ($result === NULL){ echo "preg failed, error is ".preg_last_error()."\n"; }else{ echo "success\n"; } Expected result: preg_replace shouldn't fail. Actual result: -- preg_replace returns NULL, and preg_last_error returns 2. -- Edit bug report at http://bugs.php.net/bug.php?id=54614&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54614&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54614&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54614&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54614&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54614&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54614&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54614&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54614&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54614&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54614&r=support Expected behavior: http://bugs.php.net/fix.php?id=54614&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54614&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54614&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54614&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54614&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54614&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54614&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54614&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54614&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54614&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54614&r=mysqlcfg
Bug #42424 [Com]: PHP5/PCRE fails to match long strings when ungreedy
Edit report at http://bugs.php.net/bug.php?id=42424&edit=1 ID: 42424 Comment by: php at richardneill dot org Reported by:adam-phpbugs at adam dot gs Summary:PHP5/PCRE fails to match long strings when ungreedy Status: Bogus Type: Bug Package:PCRE related Operating System: Any PHP Version:5.2.3 Block user comment: N Private report: N New Comment: This isn't bogus; it should at the very least raise an error E_NOTICE. I've just spent 7 hours tracking down a problem caused by this bug. and generating you a helpful report: http://www.richardneill.org/tmp/preg-error2.txt I do understand the rationale for the limits (though personally, I think they are 3 orders of magnitude too small, and I'd much rather my script segfaulted rather than silently introducing subtle processing errors to my data). Could we at least make sure that with display_errors (E_ALL) we get some kind of notification? At minimum, a notice would do, though ideally, this should be a fatal error. Previous Comments: [2007-08-27 11:17:15] j...@php.net In PHP 5.2.0 two new PCRE ini options were added to prevent possible stack overflows and crashes. One of them is pcre.backtrack_limit. When you set it high enough your script works as it did earlier (where no such limits existed!) $ php -dpcre.backtrack_limit=11 t.php int(1) int(1) int(1) int(1) [2007-08-25 13:16:29] adam-phpbugs at adam dot gs Description: PHP5/PCRE will fail to match on long strings when UNGREEDY, the boundary is around 100k of data. FWIW, same results if you change x* to x+ down there. Reproduce code: --- %s",str_repeat("x",6)); var_dump(preg_match("#(x*?)#",$data)); $data=sprintf("%s",str_repeat("x",7)); var_dump(preg_match("#(x*?)#",$data)); $data=sprintf("%s",str_repeat("x",7)); var_dump(preg_match("#(x*)#U",$data)); $data=sprintf("%s",str_repeat("x",7)); var_dump(preg_match("#(x*)#",$data)); ?> Expected result: all 4 expressions should match, this is what occurs with PHP 4.4.7. Actual result: -- under PHP 5.2.3: only the first and 4th expression match under PHP 4.4.7: all 4 match. -- Edit this bug report at http://bugs.php.net/bug.php?id=42424&edit=1
Req #25334 [Wfx]: edit_ini_file() function would be nice
Edit report at http://bugs.php.net/bug.php?id=25334&edit=1 ID: 25334 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary:edit_ini_file() function would be nice Status: Wont fix Type: Feature/Change Request Package:PHP options/info functions Operating System: Linux (Mandrake 9.1) PHP Version:4.3.1 Block user comment: N Private report: N New Comment: Yes...but why re-write this so many times? Since this original report, I think I've implemented such a system at least 4 times in different ways, and it seems to be a really obvious candidate for a core library. It's also quite hard to handle the awkward cases, notably preserving comments. Previous Comments: [2011-01-01 21:05:47] j...@php.net For something like this you have plenty of functions in PHP to implement it yourself in PHP code. [2003-08-31 19:25:30] php at richardneill dot org Description: Here's an idea that I think would be useful for a new function. I'd like a way to have an editable equivalent of parse_ini_file(). Many Unix programs have config files that can be edited *both* by hand, or automatically by the program. It would be nice to be able to do this in php. Eg if the file myfile.dat contains something like this: //This is a custom config or data file $foo="bar"; #comment2 $wibble="bibble"; /*comment 3*/ $aaa=3; Then, I might call the following in my script: edit_ini_file (myfile.dat, SET $foo="baz", UNSET $wibble, SET $bbb=4) And as a result, the file would be appropriately changed, without modifying the comments. In this case it would become: //This is a custom config/data file $foo="baz"; #comment2 $wibble=false; /*comment 3*/ $aaa=3 $bbb=4; I'd suggest the function should be able to: 1)SET a variable (i.e. change it if it exists, otherwise, set it) 2)UNSET a variable 3)Add a comment (after a particular variable) 4)Change a comment. If I can be of any assistance, please let me know. I hope you like the idea. Thanks for PHP - I love it :-) -- Edit this bug report at http://bugs.php.net/bug.php?id=25334&edit=1
[PHP-BUG] Req #52166 [NEW]: REF: support ionice
From: Operating system: Linux PHP version: Irrelevant Package: Program Execution Bug Type: Feature/Change Request Bug description:REF: support ionice Description: PHP has proc_nice(), but no corresponding proc_ionice(). This would be a very nice addition to have. On most current computers, the CPU bandwidth is not the limiting factor, but I/O is. So a process that has been invoked with "nice -n 19" can still bring the system to a crawl if it does a lot of disk activity. The solution is "ionice -c3". Typically: "nice -n 19 ionice -c3 $program" -- Edit bug report at http://bugs.php.net/bug.php?id=52166&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52166&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52166&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52166&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52166&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52166&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52166&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52166&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52166&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52166&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52166&r=support Expected behavior: http://bugs.php.net/fix.php?id=52166&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52166&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52166&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52166&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52166&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52166&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52166&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52166&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52166&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52166&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52166&r=mysqlcfg
Req #52073 [Bgs]: RFE: a few more options to exec()
Edit report at http://bugs.php.net/bug.php?id=52073&edit=1 ID: 52073 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary: RFE: a few more options to exec() Status: Bogus Type:Feature/Change Request Package: Program Execution PHP Version: Irrelevant New Comment: Yesbut proc_open() is often very much long-winded overkill. If I just want to get stdout and stderr as simple strings, what would be most useful would be this: exec ("echo hello >&2 ; echo world", $stdout, $stderr, $retval); // $stdout = "hello\n" // $stderr = "world\n"; // $retval = 0 the purpose here is to do everything in a minimum number of lines of code. I agree that for the entire set of suggestions, proc_open() is a better solution, but for the common case of getting stdout and stderr back separately, I'd like to see an extra parameter in exec(). Also, the documentation for exec() doesn't explain where stderr goes. Previous Comments: [2010-06-13 03:20:58] ras...@php.net This is what proc_open() is for. ---------------- [2010-06-13 02:48:15] php at richardneill dot org Description: Exec() is missing a few key features: 1. The ability to return STDERR separately from STDOUT. At the moment, we can get STDOUT back in $output, but STDERR is either logged (for php-cgi) or sent to the main script STDERR (for php-cli). The user has the choice to append "2>&1", but it would be really helpful to have stderr and stdout both returned in separate arrays. 2. The ability to choose the shell. At the moment, exec() uses apache's shell, which is usually /bin/sh (either as bash or ash depending on distro). If bash-isms are required, we can work around this with "bash -c '.. '", but it would be a nice feature. 3. If a process is forked, then we'd like to get the PID, $!. Currently this can only be achieved thus: exec ("foo & echo $!", $output) but we must sacrifice stdout for the purpose. 4. Optionally, some way to do execv("arg1", "arg2", "arg3") Test script: --- I'd suggest having a function: exec( string $command [, array &$stdout [,int &$retval [,array &$stderr [,int &$pid [,int options = BASH|SH|CSH ] ] ] ] ] ) -- Edit this bug report at http://bugs.php.net/bug.php?id=52073&edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1 ID: 52071 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary: RFE: ping Status: Wont fix Type: Feature/Change Request Package: Network related Operating System: Linux PHP Version: Irrelevant New Comment: Agreed: php would have to internally exec('ping'). That's not especially pretty, but it's no uglier than having to explicitly do it. The advantage is that the code (and all error cases) have to be handled only once within PHP, rather than by ten thousand different end-users :-) Previous Comments: [2010-06-13 03:15:15] ras...@php.net But the reason the exec() works is because you are starting a new setuid-root process to do it. There is no way to do it from a non-root process, which means you can't eliminate the exec(), which means a PHP implementation would internally have to do exec('ping') which makes no sense. -------- [2010-06-13 03:13:07] php at richardneill dot org I do see your point. On the other hand, I can (as a normal user) quite easily use ping by relying on that Setuid binary, via exec(). Wouldn't this approach work? (the key win here is to eliminate needing exec(), which tends to upset nervous managers during code-review) [2010-06-13 02:38:27] ras...@php.net This is not going to work in most PHP environments because doing raw-socket ICMP requests, like ping does requires root access. You will notice that your ping binary is setuid-root on your machine, so unless you are running PHP as root, doing it from within PHP simply won't work. If you do have root access, it isn't that hard to do with a socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but since it wouldn't work for most people, I don't see the point in adding it to PHP. ---------------- [2010-06-13 02:28:38] php at richardneill dot org Description: Surprisingly, PHP is missing the ability to ping another host (and check it's alive). So I'd like to make a request to add it. I'd suggest using something like fping rather than standard ping, as this is more script-friendly - for example, fping can be made to return immediately as soon as it discovers that a given host is alive. For example: fping -q -B1 www.php.net I know that there is Net_Ping available via PEAR, but often PEAR extensions aren't available on many hosting environments; likewise it's awkward to package a PHP web-application when the PEAR extension isn't already packaged for the distro. Is ping suficiently fundamental to be considered core? Test script: --- This command should either exist in 2 forms, or have several options. Typical use cases are: 1. Is machine X alive (and responding to Pings) 2. Can I do a DNS lookup + route to that machine 3. What is the packet loss fraction. This is easy enough to do by using exec(), but it would be nice to have a native function. Thanks. -- Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Bug #22890 [Com]: CLI setuid scripts don't run setuid
Edit report at http://bugs.php.net/bug.php?id=22890&edit=1 ID: 22890 Comment by: php at richardneill dot org Reported by: gavin at itmerge dot com Summary: CLI setuid scripts don't run setuid Status: Bogus Type: Bug Package: CGI related Operating System: Linux 2.4.18 PHP Version: 4.3.1 New Comment: In 2003, the response was: "There are no plans to implement any perl-like workaround in PHP at the present time." Might I request that, 7 years later, and with much increased use of php as a general-purpose scripting language, it might be worth re-visiting this? Previous Comments: [2003-03-26 09:38:21] il...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Uid of the binary, which is PHP is what matters, the script's uid does not matter since it is a parameter. [2003-03-26 09:36:02] ed...@php.net Modern kernels on Unix and Unix-like operating systems simply ignore set uid bit on shebang scripts (those that begin with #!). Some interpreters (like perl) choose to implement workaraounds, but if you really need to make a script suid, it is very easy to achieve so with a simple C wrapper program. There are no plans to implement any perl-like workaround in PHP at the present time. [2003-03-26 04:05:29] gavin at itmerge dot com whoops spelt posix_geteuid(); wrong :P [2003-03-26 03:27:23] gavin at itmerge dot com /* my sample script is */ #!/usr/local/bin/php /* root#chown root.vhost /scripts/myscript root#chmod 4710 /scripts/myscript root#useradd -u 1001 gavin root#usermod gavin -G vhost root#logout gavin$/scripts/myscript 1001 gavin$ i had to create /usr/local/bin/setuid_php and chmod 4710 it to be able to make my php scripts run setuid root (i'm not a perl person i don't know if perl supports setuid but I know scripts that i pass thru /bin/zsh support setuid) I don't really like having that script there :0 because A, I'm learning but i'm learing quickly that the more "permissions" you have the more you're likely to get a stuck up the rear end and essentially that lets anyone become god on my system who might find it, I think i'm going to go move it outside of /usr/local/bin right now */ -- Edit this bug report at http://bugs.php.net/bug.php?id=22890&edit=1
Req #52071 [Wfx]: RFE: ping
Edit report at http://bugs.php.net/bug.php?id=52071&edit=1 ID: 52071 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary: RFE: ping Status: Wont fix Type: Feature/Change Request Package: Network related Operating System: Linux PHP Version: Irrelevant New Comment: I do see your point. On the other hand, I can (as a normal user) quite easily use ping by relying on that Setuid binary, via exec(). Wouldn't this approach work? (the key win here is to eliminate needing exec(), which tends to upset nervous managers during code-review) Previous Comments: [2010-06-13 02:38:27] ras...@php.net This is not going to work in most PHP environments because doing raw-socket ICMP requests, like ping does requires root access. You will notice that your ping binary is setuid-root on your machine, so unless you are running PHP as root, doing it from within PHP simply won't work. If you do have root access, it isn't that hard to do with a socket_create(AF_INET, SOCK_RAW, getprotobyname('icmp')) call, but since it wouldn't work for most people, I don't see the point in adding it to PHP. -------- [2010-06-13 02:28:38] php at richardneill dot org Description: Surprisingly, PHP is missing the ability to ping another host (and check it's alive). So I'd like to make a request to add it. I'd suggest using something like fping rather than standard ping, as this is more script-friendly - for example, fping can be made to return immediately as soon as it discovers that a given host is alive. For example: fping -q -B1 www.php.net I know that there is Net_Ping available via PEAR, but often PEAR extensions aren't available on many hosting environments; likewise it's awkward to package a PHP web-application when the PEAR extension isn't already packaged for the distro. Is ping suficiently fundamental to be considered core? Test script: --- This command should either exist in 2 forms, or have several options. Typical use cases are: 1. Is machine X alive (and responding to Pings) 2. Can I do a DNS lookup + route to that machine 3. What is the packet loss fraction. This is easy enough to do by using exec(), but it would be nice to have a native function. Thanks. -- Edit this bug report at http://bugs.php.net/bug.php?id=52071&edit=1
Req #52072 [Wfx]: RFE: can we have `which`
Edit report at http://bugs.php.net/bug.php?id=52072&edit=1 ID: 52072 User updated by: php at richardneill dot org Reported by: php at richardneill dot org Summary: RFE: can we have `which` Status: Wont fix Type: Feature/Change Request Package: Filesystem function related Operating System: Linux PHP Version: Irrelevant New Comment: Thanks for your quick reply. I agree - it's trivial to do in userspace. The simplest way is just to $lastline = exec ("which $ffmpeg", $output, $retval) if (retval){ return ($lastline) }else{ return ($false) } Indeed many of the PHP functions are trivial in that sense - one could build file_get_contents() out of fopen(),file(),fclose(), or could avoid using unlink by a call to system("rm filename"). However the attraction of PHP is that so many of the required functions already exist and I don't have to write them. So I think that which() would be a useful addition. I'm particularly thinking of the cases where php-cli is an improvement on shell-scripting. Previous Comments: [2010-06-13 02:47:08] ras...@php.net This seems trivial to do in userspace to me: function which($cmd) { $paths = explode(':',$_ENV['PATH']); foreach($paths as $path) { $p = $path.'/'.$cmd; if(file_exists($p)) return $p; } return false; } -------------------- [2010-06-13 02:34:12] php at richardneill dot org Description: It would be nice if PHP had a builtin "which" command. For example, which("ffmpeg") would allow the user to check whether ffmpeg was installed, prior to calling it with exec(). Test script: --- which("ffmpeg") should return eg: /usr/bin/ffmpeg if the command exists, and is in the £PATH for exec(), or false if it doesn't exist. -- Edit this bug report at http://bugs.php.net/bug.php?id=52072&edit=1
[PHP-BUG] Req #52074 [NEW]: RFE: tempdir() countrpart to tempnam()
From: Operating system: PHP version: Irrelevant Package: Directory function related Bug Type: Feature/Change Request Bug description:RFE: tempdir() countrpart to tempnam() Description: It would be really useful to have the ability to create a tempdir, with a unique name, which we know we can write to, and will be automatically cleaned up. For example, if I want to run an external command (with exec() ) which will write to a file, where: - it must be known that file-creation can succeed - the file does not exist at the moment Test script: --- Some applications will refuse to overwrite an existing file (that we created with tempnam()), because they don't want to clobber it. What we effectively need is a race-free way to assign a temp-filename without actually creating the file. Using tmpfile() doesn't help, because we can't pass a file-handle to php's exec(). -- Edit bug report at http://bugs.php.net/bug.php?id=52074&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52074&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52074&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52074&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52074&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52074&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52074&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52074&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52074&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52074&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52074&r=support Expected behavior: http://bugs.php.net/fix.php?id=52074&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52074&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52074&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52074&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52074&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52074&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52074&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52074&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52074&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52074&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52074&r=mysqlcfg
[PHP-BUG] Req #52073 [NEW]: RFE: a few more options to exec()
From: Operating system: PHP version: Irrelevant Package: Program Execution Bug Type: Feature/Change Request Bug description:RFE: a few more options to exec() Description: Exec() is missing a few key features: 1. The ability to return STDERR separately from STDOUT. At the moment, we can get STDOUT back in $output, but STDERR is either logged (for php-cgi) or sent to the main script STDERR (for php-cli). The user has the choice to append "2>&1", but it would be really helpful to have stderr and stdout both returned in separate arrays. 2. The ability to choose the shell. At the moment, exec() uses apache's shell, which is usually /bin/sh (either as bash or ash depending on distro). If bash-isms are required, we can work around this with "bash -c '.. '", but it would be a nice feature. 3. If a process is forked, then we'd like to get the PID, $!. Currently this can only be achieved thus: exec ("foo & echo $!", $output) but we must sacrifice stdout for the purpose. 4. Optionally, some way to do execv("arg1", "arg2", "arg3") Test script: --- I'd suggest having a function: exec( string $command [, array &$stdout [,int &$retval [,array &$stderr [,int &$pid [,int options = BASH|SH|CSH ] ] ] ] ] ) -- Edit bug report at http://bugs.php.net/bug.php?id=52073&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52073&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52073&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52073&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52073&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52073&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52073&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52073&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52073&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52073&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52073&r=support Expected behavior: http://bugs.php.net/fix.php?id=52073&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52073&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52073&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52073&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52073&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52073&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52073&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52073&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52073&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52073&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52073&r=mysqlcfg
[PHP-BUG] Req #52072 [NEW]: RFE: can we have `which`
From: Operating system: Linux PHP version: Irrelevant Package: Filesystem function related Bug Type: Feature/Change Request Bug description:RFE: can we have `which` Description: It would be nice if PHP had a builtin "which" command. For example, which("ffmpeg") would allow the user to check whether ffmpeg was installed, prior to calling it with exec(). Test script: --- which("ffmpeg") should return eg: /usr/bin/ffmpeg if the command exists, and is in the £PATH for exec(), or false if it doesn't exist. -- Edit bug report at http://bugs.php.net/bug.php?id=52072&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52072&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52072&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52072&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52072&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52072&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52072&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52072&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52072&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52072&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52072&r=support Expected behavior: http://bugs.php.net/fix.php?id=52072&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52072&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52072&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52072&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52072&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52072&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52072&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52072&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52072&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52072&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52072&r=mysqlcfg
[PHP-BUG] Req #52071 [NEW]: RFE: ping
From: Operating system: Linux PHP version: Irrelevant Package: Network related Bug Type: Feature/Change Request Bug description:RFE: ping Description: Surprisingly, PHP is missing the ability to ping another host (and check it's alive). So I'd like to make a request to add it. I'd suggest using something like fping rather than standard ping, as this is more script-friendly - for example, fping can be made to return immediately as soon as it discovers that a given host is alive. For example: fping -q -B1 www.php.net I know that there is Net_Ping available via PEAR, but often PEAR extensions aren't available on many hosting environments; likewise it's awkward to package a PHP web-application when the PEAR extension isn't already packaged for the distro. Is ping suficiently fundamental to be considered core? Test script: --- This command should either exist in 2 forms, or have several options. Typical use cases are: 1. Is machine X alive (and responding to Pings) 2. Can I do a DNS lookup + route to that machine 3. What is the packet loss fraction. This is easy enough to do by using exec(), but it would be nice to have a native function. Thanks. -- Edit bug report at http://bugs.php.net/bug.php?id=52071&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52071&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52071&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52071&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52071&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52071&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52071&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52071&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52071&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52071&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52071&r=support Expected behavior: http://bugs.php.net/fix.php?id=52071&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52071&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52071&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52071&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52071&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52071&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52071&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52071&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52071&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52071&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52071&r=mysqlcfg
#48828 [NEW]: strtotime() seems surprisingly slow (3x worse than preg_match).
From: php at richardneill dot org Operating system: Linux PHP version: 6CVS-2009-07-07 (CVS) PHP Bug Type: Performance problem Bug description: strtotime() seems surprisingly slow (3x worse than preg_match). Description: I've just been troubleshooting a script whose job is to fix logfiles. Each line of the logfile has a timestamp, but only HH:MM:SS and it's missing the date. My script has to fix this. For a 500,000 line file, this takes about 2 minutes, so I investigated further. I found that strtotime() was really quite a lot slower than I expected, and that using preg_match() instead doubled the script execution speed. Is this really to be expected, or could strtotime() be optimised? Reproduce code: --- #!/usr/bin/php Expected result: I expect strtotime(), which is designed specifically for the purpose, to be faster than preg_match, which is more general-purpose. Actual result: -- strtotime() takes about 3 x longer than the brute-force approach using a regular-expression + array maths. Is that really expected? date() isn't very fast either. 42us means 100,000 CPU cycles! -- Edit bug report at http://bugs.php.net/?id=48828&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48828&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48828&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48828&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48828&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48828&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48828&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48828&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48828&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48828&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48828&r=support Expected behavior: http://bugs.php.net/fix.php?id=48828&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48828&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48828&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48828&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48828&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48828&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48828&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48828&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48828&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48828&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48828&r=mysqlcfg
#48826 [NEW]: wish: mail() to support attachments
From: php at richardneill dot org Operating system: Linux PHP version: 6CVS-2009-07-07 (CVS) PHP Bug Type: Feature/Change Request Bug description: wish: mail() to support attachments Description: It would be a really nice if mail() supported an extra parameter for attachments. Perhaps an array containing the filenames (and whose keys, if present, would be the name of the attachments). (I know there are ways of doing this by installing pear classes, but that isn't always an option. And it's awkward to do it by hand). Given that mail() is already rather overloaded, it might be worth adding another function, say mail_attach() to do it. Reproduce code: --- Current alternative: $cmd = "echo '$BODY_TEXT' | mutt -s '$SUBJECT' -a '$filename_1' -a '$filename_2' '$email'"; exec ($cmd); which is ugly, has external dependencies, only works on Linux, and will break in interesting ways if shell-quoting isn't corrected. -- Edit bug report at http://bugs.php.net/?id=48826&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48826&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48826&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48826&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48826&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48826&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48826&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48826&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48826&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48826&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48826&r=support Expected behavior: http://bugs.php.net/fix.php?id=48826&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48826&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48826&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48826&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48826&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48826&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48826&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48826&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48826&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48826&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48826&r=mysqlcfg
#48683 [Com]: stream_select returns 1 even when no streams have changed
ID: 48683 Comment by: php at richardneill dot org Reported By: php at richardneill dot org Status: Open Bug Type: Streams related Operating System: Linux PHP Version: 5.2CVS-2009-06-25 (snap) New Comment: Thank you for your explanation. I agree - I had misunderstood the docs, and PHP is behaving correctly. Previous Comments: [2009-06-25 08:37:28] sjoerd-php at linuxonly dot nl Thank you for your bug report. In your code example, you use /dev/null as blocking file. However, this is not entirely correct. As you say, /dev/null gives EOF immediately, which means stream_select sees it as ready: "The streams listed in the read array will be watched to see if characters become available for reading (more precisely, to see if a read will not block - in particular, a stream resource is also ready on end-of-file, in which case an fread() will return a zero length string)." In your loop, fread() constantly read a empty string and the file resource is constantly ready. Maybe this information already solves your problem. If it does not, please provide a better code example. [2009-06-25 04:15:01] php at richardneill dot org Description: It seems that stream_select is failing to return 0 even if all of the streams would block. I've tested the code below on multiple versions of PHP from 5.2.4 upward, and get the same result on them all. (It's possible I've misunderstood the requirements for sockets, but I've quintuple-checked this code.) Reproduce code: --- #!/usr/bin/php Expected result: I expect to see the line stream_select returned 0 repeated every 1 second. Actual result: -- I get repeated instances of: stream_select returned 1 did fread. fread is returning nothing, but still the stream_select insists that there is data available to be read! -- Edit this bug report at http://bugs.php.net/?id=48683&edit=1
#48683 [NEW]: stream_select returns 1 even when no streams have changed
From: php at richardneill dot org Operating system: Linux PHP version: 5.2CVS-2009-06-25 (snap) PHP Bug Type: Streams related Bug description: stream_select returns 1 even when no streams have changed Description: It seems that stream_select is failing to return 0 even if all of the streams would block. I've tested the code below on multiple versions of PHP from 5.2.4 upward, and get the same result on them all. (It's possible I've misunderstood the requirements for sockets, but I've quintuple-checked this code.) Reproduce code: --- #!/usr/bin/php Expected result: I expect to see the line stream_select returned 0 repeated every 1 second. Actual result: -- I get repeated instances of: stream_select returned 1 did fread. fread is returning nothing, but still the stream_select insists that there is data available to be read! -- Edit bug report at http://bugs.php.net/?id=48683&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48683&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48683&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48683&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48683&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48683&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48683&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48683&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48683&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48683&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48683&r=support Expected behavior: http://bugs.php.net/fix.php?id=48683&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48683&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48683&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48683&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48683&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48683&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48683&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48683&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48683&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48683&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48683&r=mysqlcfg
#48072 [NEW]: wish: extra strtr features similar to GNU strtr
From: php at richardneill dot org Operating system: all PHP version: 6CVS-2009-04-24 (CVS) PHP Bug Type: Feature/Change Request Bug description: wish: extra strtr features similar to GNU strtr Description: Can we have the extra features added to strtr() that are in the GNU strtr? They'd be really useful. In particular, the ability to delete certain characters from the string [currently we must resort to str_replace, which gets ugly], and to squeeze repeated characters to a single one [requires preg_replace() at the moment] This could be done by adding some predefined constants such as STRTR_DELETE, STRTR_SQUEEZE_REPEATS Reproduce code: --- In GNU tr, we can do things like echo "hello world" | tr -s "l" #results in "helo world" (duplicate 'l' removed) echo "hello world" | tr -d 'od' ('o' and 'd' removed) #results in "hell wrl" echo "hello world" | tr -s "wl" "zl" (translate AND squeeze) #results in "helo zorld" (Support for character classes might be nice too) Thank you. -- Edit bug report at http://bugs.php.net/?id=48072&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48072&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48072&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48072&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48072&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48072&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48072&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48072&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48072&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48072&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48072&r=support Expected behavior: http://bugs.php.net/fix.php?id=48072&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48072&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48072&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48072&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48072&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48072&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48072&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48072&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48072&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48072&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48072&r=mysqlcfg
#47883 [NEW]: wish: syntax error, unexpected $end should show start point
From: php at richardneill dot org Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: wish: syntax error, unexpected $end should show start point Description: If I have a script with a syntax error, such as a missing '}' somewhere, PHP will helpfully tell me that there's a problem, but direct me to look in the wrong place. The error message is as follows: Parse error: syntax error, unexpected $end in [FILENAME] at [NUMBER_OF_LAST_LINE] This is unhelpful for 2 reasons. * It isn't clear what type of syntax error would cause this - there's no way to know what character PHP was expecting to see. * I have no easy way of finding the offending line where the bug really lies, apart from commenting out parts of the source and doing a binary-search within it. Essentially, PHP is saying "You have an error, but I won't tell you where". Expected result: The following would be clearer and *far* more helpful. Syntax error: unexpected $end in [FILENAME] at LINENUM: missing an expected '}' character. (The corresponding, unmatched '{' is probably at line xxx.) Of course, it's not always possible for PHP to know which open-brace is the unmatched one - however, it could usually take a reasonable best guess by iterating *backwards* through the source, and doing: 1 $nest_depth=0 2 If a '}' is encountered, $nest_depth++ 3 If a '{' is encountered, $nest_depth-- 4 If $nest_depth == -1, we have located the open-brace that isn't closed. Print LINENUM. -- Edit bug report at http://bugs.php.net/?id=47883&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47883&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47883&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47883&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47883&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47883&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47883&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47883&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47883&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47883&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47883&r=support Expected behavior: http://bugs.php.net/fix.php?id=47883&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47883&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47883&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47883&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47883&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47883&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47883&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47883&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47883&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47883&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47883&r=mysqlcfg
#46239 [NEW]: wish: compound logical operators (nand, xor, etc)
From: php at richardneill dot org Operating system: PHP version: 6CVS-2008-10-06 (CVS) PHP Bug Type: Feature/Change Request Bug description: wish: compound logical operators (nand, xor, etc) Description: This is a request for a new set of functions, namely the more complex logical operations, NAND, NOR, XOR, XNOR etc. I suggest implementing them as functions, rather than as operators, because they can take a variable number of arguments. These would also be distinct from the bitwise operators. Of course these are pretty trivial to implement oneself as and when needed, but it would make a small increment of improvement to PHP ;-) The other advantage is in code-readability. I think that example1 is more readable than example2: $example1 = nand ($condition_1, $condition_2, $condition_3, $condition_4) $example2 = (! ($condition_1 and $condition_2 and $condition3 and $condition_4) Thanks for your time and consideration - Richard Reproduce code: --- A possible implementation: function nand($a,$b,$c,){ #cast everything to boolean return !($a and $b and $c ...); } function nor($a,$b,$c,...){ #cast to boolean return !($a or $b or $c or ...); } function new_and($a,$b,$c,...){ #note: this makes the syntax much clearer and shorter if #there are very many inputs. return ($a and $b and $c...); } #similarly, new_or() function xor($a,$b,$c,...){ $count=0; if ($a){ $count++ ;} if ($b){ $count++ ;} if ($c){ $count++ ;} ... return ($count == 1); } function xnor($a,$b,$c,...){ $count=0; if ($a){ $count++ ;} if ($b){ $count++ ;} if ($c){ $count++ ;} ... return ($count != 1); } function majority($a,$b,$c,...){ $count=0; if ($a){ $count++ ;} if ($b){ $count++ ;} if ($c){ $count++ ;} .. return ($count > $number_of_args/2); } #and any others I've missed out. -- Edit bug report at http://bugs.php.net/?id=46239&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46239&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46239&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46239&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46239&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46239&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46239&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46239&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46239&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46239&r=support Expected behavior:http://bugs.php.net/fix.php?id=46239&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46239&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46239&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46239&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46239&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46239&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46239&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46239&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46239&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46239&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46239&r=mysqlcfg
#45864 [NEW]: wish: fwrite to support direct output of bytes (not cast to string)
From: php at richardneill dot org Operating system: PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: wish: fwrite to support direct output of bytes (not cast to string) Description: fwrite() outputs to file as a string. While this is usually a sensible default, it can be rather annoying when I actually want to output raw data. I know about using chr(), but that's ugly at least. My request: add an option to fwrite that lets you output a char, rather than a string. [The chr() workaround is also not very visibly documented]. -- Edit bug report at http://bugs.php.net/?id=45864&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45864&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45864&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45864&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45864&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45864&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45864&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45864&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45864&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45864&r=support Expected behavior:http://bugs.php.net/fix.php?id=45864&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45864&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45864&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45864&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45864&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45864&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45864&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45864&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45864&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45864&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45864&r=mysqlcfg
#38610 [NEW]: wish: gmp_printf
From: php at richardneill dot org Operating system: PHP version: 5.1.5 PHP Bug Type: Feature/Change Request Bug description: wish: gmp_printf Description: According to the gmp homepage, there is a gmp_printf function. However, PHP doesn't have one. While it isn't that hard to implement by hand, it would be nice to have... (gmp_log would be nice, too!) Thanks, Richard -- Edit bug report at http://bugs.php.net/?id=38610&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38610&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38610&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38610&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38610&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38610&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38610&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38610&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38610&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38610&r=support Expected behavior:http://bugs.php.net/fix.php?id=38610&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38610&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38610&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38610&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38610&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38610&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38610&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38610&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38610&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38610&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38610&r=mysqlcfg
#28141 [Bgs]: socket_read return type: false vs "", when PHP_NORMAL_READ
ID: 28141 User updated by: php at richardneill dot org Reported By: php at richardneill dot org Status: Bogus Bug Type: Sockets related Operating System: Linux PHP Version: 4CVS, 5CVS (2005-02-14) Assigned To: andrey New Comment: Thanks. That makes sense. However, it still leaves a few problems, essentially with wrong documentation. --- 1)The documentation for socket_read http://uk.php.net/manual/en/function.socket-read.php claims: "Note: socket_read() may return a zero length string ("") indicating the end of communication (i.e. the remote end point has closed the connection)." which is obviously not true. - 2)Example 1 on the sockets page http://uk.php.net/manual/en/ref.sockets.php also supports the interpretation that False => error; null => connection closed if (false === ($buf = socket_read($msgsock, 2048, PHP_NORMAL_READ))) { echo "socket_read() failed: reason: " . socket_strerror($ret) . "\n"; break 2; } if (!$buf = trim($buf)) { continue; } -- 3)How is one to determine the difference between i)the other side closing the connection normally and ii)something going very wrong with the function? According to the documentation, "" => (i) false => (ii) In fact, it seems that false => (i) or (ii), with no way to tell "" => never actually happens Thanks for your help, Richard Previous Comments: [2005-02-14 09:10:12] [EMAIL PROTECTED] There is no bug to fix here. You're actually getting "Connection reset by peer" (ECONNRESET) and that makes recv() to return -1 -> PHP socket_read() returns an error and FALSE. Here's simplified WORKING script: #!/usr/local/bin/php [2004-07-28 21:04:13] [EMAIL PROTECTED] Assigning to myself (to get notification if i forget), changing the version. [2004-07-26 10:37:34] php at hristov dot com I will take a look later today or these days. But for now, the code in the function is : if (type == PHP_NORMAL_READ) { retval = php_read(php_sock->bsd_socket, tmpbuf, length, 0); } else { retval = recv(php_sock->bsd_socket, tmpbuf, length, 0); } if (retval == -1) { PHP_SOCKET_ERROR(php_sock, "unable to read from socket", errno); efree(tmpbuf); RETURN_FALSE; } [2004-07-18 17:13:56] php2 at richardneill dot org I've still got the same thing happening in PHP5.0.0(final) I'm having some trouble with your example, so I'm using the attached instead. It's basically copied from the php-sockets manual, but slightly modified. The key point: according to the documentation, when (socket_read()===false), it means something has gone very wrong, i.e. a fatal error. However, in practice, all this means is that the other side has closed the connection. I'm running this code as ./testsock.php and the client is simply: netcat localhost The problem is that, if netcat is killed with Ctrl-C, then the server suffers a fatal error. I don't think that it should. I've tried it under both version php-cli-4.3.7-4mdk (the current devel version from Mandrake cooker) and php-5.0.0-cli which I just compiled. In both cases, the same thing happens. Regards Richard - #!/usr/local/bin/php [2004-07-18 14:29:51] [EMAIL PROTECTED] I cannot reproduce the problem with latest PHP5. Can you provide a *full* reproducing case. My scripts are : server: client: The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/28141 -- Edit this bug report at http://bugs.php.net/?id=28141&edit=1
#31453 [Com]: array_rand() is not returning random values
ID: 31453 Comment by: php at richardneill dot org Reported By: cdturri at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Windows 2000 Advanced Server SP4 PHP Version: 5.0.3 New Comment: Arratum: the bug occurs on Mandrake 10.0, not 10.1. Nevertheless, this is 10.0 with all updates applied, so I think a security warning about that release of php would be a good idea. Previous Comments: [2005-01-09 16:00:02] php at richardneill dot org This is a rather nasty security bug, with which someone successfully attacked my website. The default passwords were generated by concatenating 2 random words from the dictionary, yet the function (which has worked fine for 3 years) suddenly started to produce exactly the same result every time! The bug occurs in this version of PHP (Mandrake's most recent stable package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug occues in both php-cli and running under apache2-2.0.48-6.8.100mdk. Here's my code, which illustrates this bug under Mandrake 10.1: Adding in an srand() will fix it, but mt_srand() will not. However, neither of these were necessary for the last 3 years, and so I imagine this bug will cause security problems for other people. [2005-01-09 15:04:01] cdturri at hotmail dot com Description: Hi guys, array_rand() is not returning random values in my scripts. I am using a multidimension array that is being loaded from an INI file with @parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows 2000 Advanced Server and a CVS build (php5-win32-200501071130.zip) under Windows as well. Bug appears on both. I don't have a Unix system to test it under PHP 5 (shame on me!) but the problem does NOT occur under Unix/Apache v 1.3.33/PHP v4.3.9. Calling srand() to seed the random number generator seems to fix the problem but the PHP manual clearly says that: "Note: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically." (http://ie2.php.net/manual/en/function.array-rand.php) mt_rand(), rand() and mt_srand() also contain notes saying that seeding is not required before calling them. Found several related bugs, but this one mentions the same issue: http://bugs.php.net/bug.php?id=26290 [17 Nov 2003 2:12pm CET] [EMAIL PROTECTED] You forgot to call srand() to generate random key. Hence the lack of random data. [17 Nov 2003 2:25pm CET] [EMAIL PROTECTED] Incorrect documentaion I'm afraid. So, it is one or the other. Either the documentation is wrong or the function is not properly calling seeding the random number generator. Could anyone please have a look? Thanks for looking at this bug. Regards, Christian Reproduce code: --- I am using this code to verify the bug: '; if ($i == 1) { $first_item = $rand_key; } if ($first_item == $rand_key) { echo ''; } } ?> You can see the bug at: http://www.turribeach.com.ar/downloads/test.php You can download the INI file I am using and the test.php from: http://www.turribeach.com.ar/downloads/PHP_Test.zip Expected result: A random key from the INI file. Actual result: -- A key but that it is not random, it is a subset of the original key array. -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31453 [Com]: array_rand() is not returning random values
ID: 31453 Comment by: php at richardneill dot org Reported By: cdturri at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Windows 2000 Advanced Server SP4 PHP Version: 5.0.3 New Comment: The affected version of mod php is this: apache2-mod_php-2.0.48_4.3.4-1mdk Previous Comments: [2005-01-09 16:07:32] php at richardneill dot org Arratum: the bug occurs on Mandrake 10.0, not 10.1. Nevertheless, this is 10.0 with all updates applied, so I think a security warning about that release of php would be a good idea. [2005-01-09 16:00:02] php at richardneill dot org This is a rather nasty security bug, with which someone successfully attacked my website. The default passwords were generated by concatenating 2 random words from the dictionary, yet the function (which has worked fine for 3 years) suddenly started to produce exactly the same result every time! The bug occurs in this version of PHP (Mandrake's most recent stable package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug occues in both php-cli and running under apache2-2.0.48-6.8.100mdk. Here's my code, which illustrates this bug under Mandrake 10.1: Adding in an srand() will fix it, but mt_srand() will not. However, neither of these were necessary for the last 3 years, and so I imagine this bug will cause security problems for other people. [2005-01-09 15:04:01] cdturri at hotmail dot com Description: Hi guys, array_rand() is not returning random values in my scripts. I am using a multidimension array that is being loaded from an INI file with @parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows 2000 Advanced Server and a CVS build (php5-win32-200501071130.zip) under Windows as well. Bug appears on both. I don't have a Unix system to test it under PHP 5 (shame on me!) but the problem does NOT occur under Unix/Apache v 1.3.33/PHP v4.3.9. Calling srand() to seed the random number generator seems to fix the problem but the PHP manual clearly says that: "Note: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically." (http://ie2.php.net/manual/en/function.array-rand.php) mt_rand(), rand() and mt_srand() also contain notes saying that seeding is not required before calling them. Found several related bugs, but this one mentions the same issue: http://bugs.php.net/bug.php?id=26290 [17 Nov 2003 2:12pm CET] [EMAIL PROTECTED] You forgot to call srand() to generate random key. Hence the lack of random data. [17 Nov 2003 2:25pm CET] [EMAIL PROTECTED] Incorrect documentaion I'm afraid. So, it is one or the other. Either the documentation is wrong or the function is not properly calling seeding the random number generator. Could anyone please have a look? Thanks for looking at this bug. Regards, Christian Reproduce code: --- I am using this code to verify the bug: '; if ($i == 1) { $first_item = $rand_key; } if ($first_item == $rand_key) { echo ''; } } ?> You can see the bug at: http://www.turribeach.com.ar/downloads/test.php You can download the INI file I am using and the test.php from: http://www.turribeach.com.ar/downloads/PHP_Test.zip Expected result: A random key from the INI file. Actual result: -- A key but that it is not random, it is a subset of the original key array. -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#31453 [Com]: array_rand() is not returning random values
ID: 31453 Comment by: php at richardneill dot org Reported By: cdturri at hotmail dot com Status: Open Bug Type: Arrays related Operating System: Windows 2000 Advanced Server SP4 PHP Version: 5.0.3 New Comment: This is a rather nasty security bug, with which someone successfully attacked my website. The default passwords were generated by concatenating 2 random words from the dictionary, yet the function (which has worked fine for 3 years) suddenly started to produce exactly the same result every time! The bug occurs in this version of PHP (Mandrake's most recent stable package): PHP 4.3.4 (cli) (built: Dec 16 2004 18:39:58); but not in the cooker package (PHP 4.3.10 (cli) (built: Dec 16 2004 15:44:17). The bug occues in both php-cli and running under apache2-2.0.48-6.8.100mdk. Here's my code, which illustrates this bug under Mandrake 10.1: Adding in an srand() will fix it, but mt_srand() will not. However, neither of these were necessary for the last 3 years, and so I imagine this bug will cause security problems for other people. Previous Comments: [2005-01-09 15:04:01] cdturri at hotmail dot com Description: Hi guys, array_rand() is not returning random values in my scripts. I am using a multidimension array that is being loaded from an INI file with @parse_ini_file(). Tested under Apache v2.0.52/PHP v5.0.3 on Windows 2000 Advanced Server and a CVS build (php5-win32-200501071130.zip) under Windows as well. Bug appears on both. I don't have a Unix system to test it under PHP 5 (shame on me!) but the problem does NOT occur under Unix/Apache v 1.3.33/PHP v4.3.9. Calling srand() to seed the random number generator seems to fix the problem but the PHP manual clearly says that: "Note: As of PHP 4.2.0, there is no need to seed the random number generator with srand() or mt_srand() as this is now done automatically." (http://ie2.php.net/manual/en/function.array-rand.php) mt_rand(), rand() and mt_srand() also contain notes saying that seeding is not required before calling them. Found several related bugs, but this one mentions the same issue: http://bugs.php.net/bug.php?id=26290 [17 Nov 2003 2:12pm CET] [EMAIL PROTECTED] You forgot to call srand() to generate random key. Hence the lack of random data. [17 Nov 2003 2:25pm CET] [EMAIL PROTECTED] Incorrect documentaion I'm afraid. So, it is one or the other. Either the documentation is wrong or the function is not properly calling seeding the random number generator. Could anyone please have a look? Thanks for looking at this bug. Regards, Christian Reproduce code: --- I am using this code to verify the bug: '; if ($i == 1) { $first_item = $rand_key; } if ($first_item == $rand_key) { echo ''; } } ?> You can see the bug at: http://www.turribeach.com.ar/downloads/test.php You can download the INI file I am using and the test.php from: http://www.turribeach.com.ar/downloads/PHP_Test.zip Expected result: A random key from the INI file. Actual result: -- A key but that it is not random, it is a subset of the original key array. -- Edit this bug report at http://bugs.php.net/?id=31453&edit=1
#30698 [Fbk->Opn]: preg_replace with /e does not escape single quotes as per documentation
ID: 30698 User updated by: php at richardneill dot org Reported By: php at richardneill dot org -Status: Feedback +Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 4.3.9 New Comment: I hope this test case is more useful. Previous Comments: [2004-11-10 18:24:12] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Btw, the example from docs works just fine for me. [2004-11-06 08:19:13] php at richardneill dot org Sorry - that should have been filed as PCRE related Richard [2004-11-06 08:17:25] php at richardneill dot org Description: The documentation for preg_replace states that /e will cause it to add extra slashes to single and double quotes. This means that, if one has magic_quotes on, one must filter out the spurious new backslashes, using something like: $block=str_replace(array('\'','"'),array('\\\'','\\"'), $block); However, in fact, it appears that preg_replace is adding the backslashes to double quotes, but NOT to single quotes. There's also a useful comment here: http://uk2.php.net/manual/en/function.preg-replace.php steven -a-t- acko dot net 08-Feb-2004 05:45 Reproduce code: --- FAILS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END $quote_font_end\n\n'", $message); WORKS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock(\"\\3\",$quote).' END $quote_font_end\n\n'", $message); Expected result: I'm not sure whether this is simply a documentation bug, but it's very weird behaviour! It is also a nasty one, because it can leave the database vulnerable. Thanks for your help. -- Edit this bug report at http://bugs.php.net/?id=30698&edit=1
#30698 [Opn]: preg_replace with /e does not escape single quotes as per documentation
ID: 30698 User updated by: php at richardneill dot org Reported By: php at richardneill dot org Status: Open -Bug Type: Feature/Change Request +Bug Type: PCRE related Operating System: Linux PHP Version: 4.3.9 New Comment: Sorry - that should have been filed as PCRE related Richard Previous Comments: [2004-11-06 08:17:25] php at richardneill dot org Description: The documentation for preg_replace states that /e will cause it to add extra slashes to single and double quotes. This means that, if one has magic_quotes on, one must filter out the spurious new backslashes, using something like: $block=str_replace(array('\'','"'),array('\\\'','\\"'), $block); However, in fact, it appears that preg_replace is adding the backslashes to double quotes, but NOT to single quotes. There's also a useful comment here: http://uk2.php.net/manual/en/function.preg-replace.php steven -a-t- acko dot net 08-Feb-2004 05:45 Reproduce code: --- FAILS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END $quote_font_end\n\n'", $message); WORKS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock(\"\\3\",$quote).' END $quote_font_end\n\n'", $message); Expected result: I'm not sure whether this is simply a documentation bug, but it's very weird behaviour! It is also a nasty one, because it can leave the database vulnerable. Thanks for your help. -- Edit this bug report at http://bugs.php.net/?id=30698&edit=1
#30698 [NEW]: preg_replace with /e does not escape single quotes as per documentation
From: php at richardneill dot org Operating system: Linux PHP version: 4.3.9 PHP Bug Type: Feature/Change Request Bug description: preg_replace with /e does not escape single quotes as per documentation Description: The documentation for preg_replace states that /e will cause it to add extra slashes to single and double quotes. This means that, if one has magic_quotes on, one must filter out the spurious new backslashes, using something like: $block=str_replace(array('\'','"'),array('\\\'','\\"'), $block); However, in fact, it appears that preg_replace is adding the backslashes to double quotes, but NOT to single quotes. There's also a useful comment here: http://uk2.php.net/manual/en/function.preg-replace.php steven -a-t- acko dot net 08-Feb-2004 05:45 Reproduce code: --- FAILS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock('\\3',$quote).' END $quote_font_end\n\n'", $message); WORKS: $message=preg_replace("/((?<=(\n))|(?<=^))( *>(.*))(\n\n|$)/seU", "'$quote_font_start BEGIN'.fixblock(\"\\3\",$quote).' END $quote_font_end\n\n'", $message); Expected result: I'm not sure whether this is simply a documentation bug, but it's very weird behaviour! It is also a nasty one, because it can leave the database vulnerable. Thanks for your help. -- Edit bug report at http://bugs.php.net/?id=30698&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30698&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30698&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30698&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30698&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30698&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30698&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30698&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30698&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30698&r=support Expected behavior: http://bugs.php.net/fix.php?id=30698&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30698&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30698&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30698&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30698&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30698&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30698&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30698&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30698&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30698&r=mysqlcfg
#28141 [NoF->Opn]: socket_read return type: false vs ""
ID: 28141 User updated by: php at richardneill dot org Reported By: php at richardneill dot org -Status: No Feedback +Status: Open Bug Type: Sockets related Operating System: Linux PHP Version: 5.0.0RC1 New Comment: re-setting to open as requested by automatic email. Sorry - I think I confused your system by commenting as another user rather than as the original submitter. Previous Comments: [2004-07-26 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-07-18 17:13:56] php2 at richardneill dot org I've still got the same thing happening in PHP5.0.0(final) I'm having some trouble with your example, so I'm using the attached instead. It's basically copied from the php-sockets manual, but slightly modified. The key point: according to the documentation, when (socket_read()===false), it means something has gone very wrong, i.e. a fatal error. However, in practice, all this means is that the other side has closed the connection. I'm running this code as ./testsock.php and the client is simply: netcat localhost The problem is that, if netcat is killed with Ctrl-C, then the server suffers a fatal error. I don't think that it should. I've tried it under both version php-cli-4.3.7-4mdk (the current devel version from Mandrake cooker) and php-5.0.0-cli which I just compiled. In both cases, the same thing happens. Regards Richard - #!/usr/local/bin/php [2004-07-18 14:29:51] [EMAIL PROTECTED] I cannot reproduce the problem with latest PHP5. Can you provide a *full* reproducing case. My scripts are : server: client: ------------ [2004-04-28 04:54:43] php at richardneill dot org This is still present in RC2 ------------ [2004-04-25 06:56:24] php at richardneill dot org Description: According to the documentation, socket_read() can return: 1)A string - normal data 2)An empty string "" - the other end closed the connection 3)false - something went wrong. But it seems to be returning false on connection close. Reproduce code: --- $buffer=socket_read($socket,2048,PHP_NORMAL_READ); if ($buffer===false){ echo "Error: socket_read() failed: reason: ".socket_strerror(socket_last_error())." \n"; exit (1); }elseif ($buffer==''){ echo "Socket $socket returned an empty string. Closing connection\n"; socket_close($socket); }else{ echo "Received data".trim($buffer)."\n"; } Expected result: I'm using netcat as a client, and then killing the netcat process with Ctrl-C to simulate remote host disconnecting. I expect to see the socket close. Actual result: -- Actually, the php script exits, because socket_read returns false instead of "". This may be a bug in the documentation for socket_read, rather than in its behaviour. Thanks for your help - Richard -- Edit this bug report at http://bugs.php.net/?id=28141&edit=1
#28646 [Opn]: RFE: function to fix microsoft "smart quotes"and other wrong characters
ID: 28646 User updated by: php at richardneill dot org Reported By: php at richardneill dot org Status: Open Bug Type:Feature/Change Request PHP Version: 4.3.6 New Comment: For safety's sake, it's probably wiser to have < > \` \' \" as the replacements. Otherwise, we have a nice big security hole, since magic_quotes gets bypassed. Previous Comments: ---- [2004-06-05 23:55:34] php at richardneill dot org Description: Feature request: str_demoronise() On my website, I often find users pasting content that was written in Microsoft Word, and which contains undisplayable "ASCII" characters where there should be single/double quotes. Anyone viewing the result on a non-MS platform gets to see rectangles instead of quotes. The problem has been solved in perl here: http://www.fourmilab.ch/webtools/demoroniser/ I quote: Microsoft use their own "extension" to Latin-1, in which a variety of characters which do not appear in Latin-1 are inserted in the range 0x82 through 0x95--this having the merit of being incompatible with both Latin-1 and Unicode, which reserve this region for additional control characters. = I'd like to suggest the addition of a str_demoronise() function which fixes these wrong characters, and replaces them by the correct ASCII. Reproduce code: --- >From the source of demoroniser, here are the substitutions made. The MS column is what Microsoft use (in Hex); the FIX column is the replacement: MS FIX 0x82, 0x83f 0x84,, 0x85... 0x88^ 0x89' °/°°'<-- whitsepace; no '' quotes 0x8B< 0x8COe 0x91` 0x92' 0x93" 0x94" 0x95* 0x96- 0x97-- 0x98~ 0x99TM 0x9B> 0x9Coe -- Edit this bug report at http://bugs.php.net/?id=28646&edit=1
#28646 [NEW]: RFE: function to fix microsoft "smart quotes"and other wrong characters
From: php at richardneill dot org Operating system: PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: RFE: function to fix microsoft "smart quotes"and other wrong characters Description: Feature request: str_demoronise() On my website, I often find users pasting content that was written in Microsoft Word, and which contains undisplayable "ASCII" characters where there should be single/double quotes. Anyone viewing the result on a non-MS platform gets to see rectangles instead of quotes. The problem has been solved in perl here: http://www.fourmilab.ch/webtools/demoroniser/ I quote: Microsoft use their own "extension" to Latin-1, in which a variety of characters which do not appear in Latin-1 are inserted in the range 0x82 through 0x95--this having the merit of being incompatible with both Latin-1 and Unicode, which reserve this region for additional control characters. = I'd like to suggest the addition of a str_demoronise() function which fixes these wrong characters, and replaces them by the correct ASCII. Reproduce code: --- >From the source of demoroniser, here are the substitutions made. The MS column is what Microsoft use (in Hex); the FIX column is the replacement: MS FIX 0x82, 0x83f 0x84,, 0x85... 0x88^ 0x89' °/°°'<-- whitsepace; no '' quotes 0x8B< 0x8COe 0x91` 0x92' 0x93" 0x94" 0x95* 0x96- 0x97-- 0x98~ 0x99TM 0x9B> 0x9Coe -- Edit bug report at http://bugs.php.net/?id=28646&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28646&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28646&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28646&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28646&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28646&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28646&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28646&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28646&r=support Expected behavior: http://bugs.php.net/fix.php?id=28646&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28646&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28646&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28646&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28646&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28646&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28646&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28646&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28646&r=float
#28141 [Opn]: socket_read return type: false vs ""
ID: 28141 User updated by: php at richardneill dot org -Summary: sokcet_read return type: false vs "" Reported By: php at richardneill dot org Status: Open Bug Type: Sockets related Operating System: Linux PHP Version: 5.0.0RC1 New Comment: This is still present in RC2 Previous Comments: [2004-04-25 06:56:24] php at richardneill dot org Description: According to the documentation, socket_read() can return: 1)A string - normal data 2)An empty string "" - the other end closed the connection 3)false - something went wrong. But it seems to be returning false on connection close. Reproduce code: --- $buffer=socket_read($socket,2048,PHP_NORMAL_READ); if ($buffer===false){ echo "Error: socket_read() failed: reason: ".socket_strerror(socket_last_error())." \n"; exit (1); }elseif ($buffer==''){ echo "Socket $socket returned an empty string. Closing connection\n"; socket_close($socket); }else{ echo "Received data".trim($buffer)."\n"; } Expected result: I'm using netcat as a client, and then killing the netcat process with Ctrl-C to simulate remote host disconnecting. I expect to see the socket close. Actual result: -- Actually, the php script exits, because socket_read returns false instead of "". This may be a bug in the documentation for socket_read, rather than in its behaviour. Thanks for your help - Richard -- Edit this bug report at http://bugs.php.net/?id=28141&edit=1
#28141 [NEW]: sokcet_read return type: false vs ""
From: php at richardneill dot org Operating system: Linux PHP version: 5.0.0RC1 PHP Bug Type: Sockets related Bug description: sokcet_read return type: false vs "" Description: According to the documentation, socket_read() can return: 1)A string - normal data 2)An empty string "" - the other end closed the connection 3)false - something went wrong. But it seems to be returning false on connection close. Reproduce code: --- $buffer=socket_read($socket,2048,PHP_NORMAL_READ); if ($buffer===false){ echo "Error: socket_read() failed: reason: ".socket_strerror(socket_last_error())." \n"; exit (1); }elseif ($buffer==''){ echo "Socket $socket returned an empty string. Closing connection\n"; socket_close($socket); }else{ echo "Received data".trim($buffer)."\n"; } Expected result: I'm using netcat as a client, and then killing the netcat process with Ctrl-C to simulate remote host disconnecting. I expect to see the socket close. Actual result: -- Actually, the php script exits, because socket_read returns false instead of "". This may be a bug in the documentation for socket_read, rather than in its behaviour. Thanks for your help - Richard -- Edit bug report at http://bugs.php.net/?id=28141&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28141&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28141&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28141&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28141&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28141&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28141&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28141&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28141&r=support Expected behavior: http://bugs.php.net/fix.php?id=28141&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28141&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28141&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28141&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28141&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28141&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28141&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28141&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28141&r=float
#28140 [Fbk->Opn]: html_errors is *on* for CLI
ID: 28140 User updated by: php at richardneill dot org Reported By: php at richardneill dot org -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Linux PHP Version: 5.0.0RC1 New Comment: Quite right - I do apologise. I had simply assumed that a script which began with #!/usr/local/bin/php would be the CLI version. (That's how it used to work, with the Mandrake rpms, but I had to compile it myself to have --enable-sockets), and the default wasn't what I expected. Sorry for wasting your time. Richard Previous Comments: [2004-04-25 05:30:22] [EMAIL PROTECTED] Not reproducable here, double check that you are indeed using the CLI version of PHP: /usr/local/bin/php -v [2004-04-25 04:06:54] php at richardneill dot org Description: Using php from the command line, the error messages include html tags. The html_errors directive is supposed to be overridden for PHP-CLI: http://uk.php.net/manual/en/features.commandline.php Reproduce code: --- #!/usr/local/bin/php -q run this from the command line. Expected result: Parse error: parse error, expecting `','' or `';'' in /home/rjn/test.php on line 4 (this is what I see using PHP 4.3.3) Actual result: -- Parse error: parse error, unexpected T_VARIABLE, expecting ',' or ';' in /home/rjn/test/php on line 4 (this is what I see in PHP 5.0.0RC1) -- Edit this bug report at http://bugs.php.net/?id=28140&edit=1
#28140 [NEW]: html_errors is *on* for CLI
From: php at richardneill dot org Operating system: Linux PHP version: 5.0.0RC1 PHP Bug Type: CGI related Bug description: html_errors is *on* for CLI Description: Using php from the command line, the error messages include html tags. The html_errors directive is supposed to be overridden for PHP-CLI: http://uk.php.net/manual/en/features.commandline.php Reproduce code: --- #!/usr/local/bin/php -q run this from the command line. Expected result: Parse error: parse error, expecting `','' or `';'' in /home/rjn/test.php on line 4 (this is what I see using PHP 4.3.3) Actual result: -- Parse error: parse error, unexpected T_VARIABLE, expecting ',' or ';' in /home/rjn/test/php on line 4 (this is what I see in PHP 5.0.0RC1) -- Edit bug report at http://bugs.php.net/?id=28140&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28140&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28140&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28140&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28140&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28140&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28140&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28140&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28140&r=support Expected behavior: http://bugs.php.net/fix.php?id=28140&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28140&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28140&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28140&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28140&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28140&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28140&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28140&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28140&r=float
#26818 [Opn]: getopt parses incorrectly
ID: 26818 User updated by: php at richardneill dot org Reported By: php at richardneill dot org Status: Open Bug Type: Feature/Change Request Operating System: Linux (Mandrake) PHP Version: 4.3.4 New Comment: I do apologise - I thought that GNU's getopts was smarter than that! So, I now agree that PHP is doing the standards-compliant thing. I still think it would be useful if PHP had an option to parse options "my way" :-) Thanks for your help. Richard Previous Comments: [2004-01-06 18:58:52] [EMAIL PROTECTED] The function uses the GNU getopt function, so the behaviour is exactly same. Moved the FRs. [2004-01-06 17:53:42] php at richardneill dot org I agree with you about the manual. BUT, nevertheless, this is not the behaviour that it should have. Currently, it isn't consistent with the normal (GNU-like) command line behaviour. If options -x and -y are supposed to take values, then if I enter the command: ./getopt.php -a -x -y bar it can mean only one of 2 things: 1)I, the user have made a mistake at the command line, and omitted the value for $x. The script should be able to test for this as an error. 2)I meant to assign a null or false value to $x (possible, not likely) It is *very* unlikely that I meant to assign the value '-y' to $x. (If I had meant to do this, I would have double quoted it). Please can we at least have an option within getopts to parse options in a standard manner? I'd suggest doing the following: If an option expects a value, read along the command line until reaching the next '-' or the end of line. This value (or false if it is null) is placed in the options_array. Thank you. Richard [2004-01-06 17:30:17] [EMAIL PROTECTED] RTFM: "It does not matter if an argument has leading white space." (it means also: whitespace is omitted) ---------------- [2004-01-06 14:52:41] php at richardneill dot org Description: When parsing options, if the command line arguments are WRONG, php mangles them in such a way as to give an incorrect, but valid response. Eg my program normally takes arguments: ./getopt.php -a -x foo -y bar (ie. option a takes no value; options x,y take values) Therefore, if I run it as ./getopt.php -a -x -y bar this is clearly a mistake: I omitted the value for -x. HOWEVER, php assumes that I wanted the value for -x to be '-y' If this is "a feature, not a bug", it might be worth documentig it, or providing a switch to enable the behaviour I'd expect. Thank you. Reproduce code: --- #!/usr/bin/php $value){ echo "\tkey:\t $key\t value is:\t $value"; if ($value===false){ echo "\t[FALSE]"; } echo "\n"; } echo "\n"; #N.B. If options -x and -y each expect an argument, then one might expect # 'getopt.php -x -y foo' to result in $key="x",$value=false; $key="y",$value="foo" # BUT actually, the result is $key="x",$value="-y"; and foo is left over. Expected result: [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: [FALSE] key: y value is: bar Actual result: -- [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: -y -- Edit this bug report at http://bugs.php.net/?id=26818&edit=1
#26818 [Bgs->Opn]: getopt parses incorrectly
ID: 26818 User updated by: php at richardneill dot org Reported By: php at richardneill dot org -Status: Bogus +Status: Open Bug Type: CGI related Operating System: Linux (Mandrake) PHP Version: 4.3.4 New Comment: I agree with you about the manual. BUT, nevertheless, this is not the behaviour that it should have. Currently, it isn't consistent with the normal (GNU-like) command line behaviour. If options -x and -y are supposed to take values, then if I enter the command: ./getopt.php -a -x -y bar it can mean only one of 2 things: 1)I, the user have made a mistake at the command line, and omitted the value for $x. The script should be able to test for this as an error. 2)I meant to assign a null or false value to $x (possible, not likely) It is *very* unlikely that I meant to assign the value '-y' to $x. (If I had meant to do this, I would have double quoted it). Please can we at least have an option within getopts to parse options in a standard manner? I'd suggest doing the following: If an option expects a value, read along the command line until reaching the next '-' or the end of line. This value (or false if it is null) is placed in the options_array. Thank you. Richard Previous Comments: [2004-01-06 17:30:17] [EMAIL PROTECTED] RTFM: "It does not matter if an argument has leading white space." (it means also: whitespace is omitted) -------- [2004-01-06 14:52:41] php at richardneill dot org Description: When parsing options, if the command line arguments are WRONG, php mangles them in such a way as to give an incorrect, but valid response. Eg my program normally takes arguments: ./getopt.php -a -x foo -y bar (ie. option a takes no value; options x,y take values) Therefore, if I run it as ./getopt.php -a -x -y bar this is clearly a mistake: I omitted the value for -x. HOWEVER, php assumes that I wanted the value for -x to be '-y' If this is "a feature, not a bug", it might be worth documentig it, or providing a switch to enable the behaviour I'd expect. Thank you. Reproduce code: --- #!/usr/bin/php $value){ echo "\tkey:\t $key\t value is:\t $value"; if ($value===false){ echo "\t[FALSE]"; } echo "\n"; } echo "\n"; #N.B. If options -x and -y each expect an argument, then one might expect # 'getopt.php -x -y foo' to result in $key="x",$value=false; $key="y",$value="foo" # BUT actually, the result is $key="x",$value="-y"; and foo is left over. Expected result: [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: [FALSE] key: y value is: bar Actual result: -- [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: -y -- Edit this bug report at http://bugs.php.net/?id=26818&edit=1
#26818 [NEW]: getopt parses incorrectly
From: php at richardneill dot org Operating system: Linux (Mandrake) PHP version: 4.3.4 PHP Bug Type: CGI related Bug description: getopt parses incorrectly Description: When parsing options, if the command line arguments are WRONG, php mangles them in such a way as to give an incorrect, but valid response. Eg my program normally takes arguments: ./getopt.php -a -x foo -y bar (ie. option a takes no value; options x,y take values) Therefore, if I run it as ./getopt.php -a -x -y bar this is clearly a mistake: I omitted the value for -x. HOWEVER, php assumes that I wanted the value for -x to be '-y' If this is "a feature, not a bug", it might be worth documentig it, or providing a switch to enable the behaviour I'd expect. Thank you. Reproduce code: --- #!/usr/bin/php $value){ echo "\tkey:\t $key\t value is:\t $value"; if ($value===false){ echo "\t[FALSE]"; } echo "\n"; } echo "\n"; #N.B. If options -x and -y each expect an argument, then one might expect # 'getopt.php -x -y foo' to result in $key="x",$value=false; $key="y",$value="foo" # BUT actually, the result is $key="x",$value="-y"; and foo is left over. Expected result: [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: [FALSE] key: y value is: bar Actual result: -- [rjn]$ ./getopt.php -a -x -y bar Here are the results of getopt: key: a value is: [FALSE] key: x value is: -y -- Edit bug report at http://bugs.php.net/?id=26818&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26818&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26818&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26818&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26818&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26818&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26818&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26818&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26818&r=support Expected behavior: http://bugs.php.net/fix.php?id=26818&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26818&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26818&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26818&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26818&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26818&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26818&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26818&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26818&r=float
#25334 [NEW]: edit_ini_file() function would be nice
From: php at richardneill dot org Operating system: Linux (Mandrake 9.1) PHP version: 4.3.1 PHP Bug Type: Feature/Change Request Bug description: edit_ini_file() function would be nice Description: Here's an idea that I think would be useful for a new function. I'd like a way to have an editable equivalent of parse_ini_file(). Many Unix programs have config files that can be edited *both* by hand, or automatically by the program. It would be nice to be able to do this in php. Eg if the file myfile.dat contains something like this: //This is a custom config or data file $foo="bar"; #comment2 $wibble="bibble"; /*comment 3*/ $aaa=3; Then, I might call the following in my script: edit_ini_file (myfile.dat, SET $foo="baz", UNSET $wibble, SET $bbb=4) And as a result, the file would be appropriately changed, without modifying the comments. In this case it would become: //This is a custom config/data file $foo="baz"; #comment2 $wibble=false; /*comment 3*/ $aaa=3 $bbb=4; I'd suggest the function should be able to: 1)SET a variable (i.e. change it if it exists, otherwise, set it) 2)UNSET a variable 3)Add a comment (after a particular variable) 4)Change a comment. If I can be of any assistance, please let me know. I hope you like the idea. Thanks for PHP - I love it :-) -- Edit bug report at http://bugs.php.net/?id=25334&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25334&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25334&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25334&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25334&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25334&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25334&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25334&r=support Expected behavior: http://bugs.php.net/fix.php?id=25334&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25334&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25334&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25334&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25334&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25334&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25334&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25334&r=gnused