Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=1 ID: 49764 Comment by: codeslinger at compsalot dot com Reported by:tec at baufi24 dot de Summary:number_format() fails (randomly?) Status: Assigned Type: Bug Package:Math related Operating System: Windows PHP Version:* Assigned To:pajoye Block user comment: N New Comment: it's not random, it's just very hard to reproduce. only certain specific values will trigger this bug. and the weird thing is that the specific value changes from build to build and with different oses. this bug is a dup of the many other existing reports about this bug. bugs 43487, 47304, 47716, 47732, 51396 etc.. this bug has been encountered in: php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9... it has been found on Windows 2000, Windows XP, Windows 2003, ubuntu, mandriva. This bug has been reproduced both with and without xdebug and/or zend debugger. You want to reproduce this bug???!!! it's very easy, I will give you a one-liner install ubuntu 8.0.4 install the standard php that comes with ubuntu 8.0.4 now run this: echo (string) (double) -0.0; actual result: -0.0: Note that changing the float percision greatly affects the bug. The thing is that the value is very specific to the actual build and the actual os. For instance it was reported that on Windows nt 5.2 (2003?) the following will fail: echo round(1451,2); actual result: 1450.:0 It has also been reported that using BCMath helps but does not totally solve this problem 3 out of 4 were fixed. But despite all of the above, this bug keeps getting blown off as not repro!!! :-( Consider the following true story: once upon a time, there was a German insurance company sued by a client whoâd lost a lot of money through the insurance companyâs flawed bookkeeping. The insurance company went into a panic and started hunting the bug and were able to prove it was caused by customized software theyâd bought from a German software house. They sued the software house. The software house went into a panic and started hunting the bug further. They were able to prove the bug was actually caused by a flaw in Lotus Symphony. So they sued Lotus. Now Lotus went into a panic and started hunting the bug further. They were able to prove the bug was actually in their C compiler. The compiler was generating a short jump when instead it should have been generating a long jump. === I first encountered this bug in a billing program that I wrote... and so far nobody seems to give a flying fig about fixing this bug. I do not wish to get sued by an irate customer... especially since I am still in start-up mode and have yet to make a single nickel, otherwise I'd be willing to throw some money at php devs if that's what it took to get this fixed. How about somebody else stepping up to the plate, there are some deep pockets out there, come on ibm, microsoft, ??? where is your community spirit? If there is even one single math error in php that is too much. PHP is widely used for eCommerce $ and math accuracy is critical. If I did not have such a huge investment in php code and skills I would have already jumped ship to a different language, as it is, I'm giving it very serious consideration. This situation is very ungood. Just randomly using a different version of php (the latest snapshot) does not solve anything. It has already been established that every single version of php fails with different values. So changing the version will cause that specific value to no longer fail. But until the *cause* of the bug is *actually understood*... we still have lurking failures waiting to zap us. Also the newer versions of php do not come with full library support, and thus *upgrades are impossible* for many of us who need/require those libraries. Just as others have asked, I too shall ask, why is the library support missing??? When will we get it? newer versions of php are worthless without the libraries. Previous Comments: [2010-06-13 19:35:21] paj...@php.net Nothing changed here. [2010-06-13 19:26:12] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-05-13 21:26:19] derek dot ethier at humber dot ca I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: In Summary: As Reported by Multiple People Windows XP (32 bit) PHP 5.2.4 Fails Windows XP (32 bit) PHP 5.2.5 Works Windows 2000 (32 bit) PHP 5.2.5 Works Windows XP (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.11 Fails Windows 2003 (?? bit) PHP 5.2.12 Fails Windows 2003 (?? bit) PHP 5.2.13 Fails Ubuntu 8 (32bit) PHP 5.2.4 Fails Ubuntu 8 (32bit) PHP 5.2.9 (custom build) Works Ubuntu 9 (64bit) PHP 5.2.10 Works Mandriva 2008 (32bit 64bit) PHP 5.2.4 Works Mandriva 2008 (32bit 64bit) Unpatched PHP 5.2.5 Fails This bug has been reported by multiple people. The above list is the combination of my own testing plus what I found reported by other people. The windows oses are all using the STOCK BUILD as provided by php.net It is very important to understand that the specific values which fail are highly variable. A specific value which fails on one os/php version does not necessarily fail on a different combination of os+php, but a different value will fail instead. It is also important to realize that given the obscurity and variability of this bug, just because a particular version of php is reported as working, does not guarantee that the bug does not exist, it only says that so far no one has reported encountering a specific value which triggers this bug. All of the following are thought to influence the specific behavior and reproducibility of this bug. The number of cpu bits The operating system The specific version of php The compiler flags that were used to build php The precision setting for php The format specifier/precision in an sprintf statement sprintf versus implied (string) conversion It is also possible that the floating point hardware could have an influence on the reproducibility of this bug. Since the WORK-AROUND did not work for John, it would appear that we still have a problem which needs to be solved. Previous Comments: [2010-05-24 03:17:36] john dot smith dot 1964 at gmail dot com This problem isn't fixed for us by adding ini_set(precision, 16);. Our PHP install is stock off the website (5.2.4 and 5.2.13, for instance) and our box runs Windows 2003. [2010-05-24 02:18:46] paj...@php.net . [2010-05-24 02:04:27] codeslinger at compsalot dot com Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set(precision, 16); End of Problem End of Bug... Like Good Day Eh? [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. [2010-05-23 09:38:47] codeslinger at compsalot dot com In response to johan...@php.net above. Let me just very politely reiterate that I originally encountered this bug on the STOCK WINDOWS BUILD from php.net, therefore to dismiss this bug because it is ubuntu specific
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: P.S. Please note that in my own testing I have verified that the presence or absence of the xdebug and zend debug extensions do not alter the behavior of this bug, this was verified on Windows. Also note how for instance 5.2.4 fails on Windows and on Ubuntu but works on Mandriva (or at least was not found to fail on Mandriva). Also I can tell you from my own testing that the specific values which fail on Windows are very different from the specific values which fail on Unbuntu, when tested on the same computer. The only thing which can be said with some level of confidence is that all of the failures involve numbers with the digit 9 in them. Since these are 58? digit numbers and only a very few specific values fail, the potential to NOT see a failure is huge. Previous Comments: [2010-05-24 13:59:45] paj...@php.net Please read my last comment and provide the info I asked there. Without that, there is not a chance to get anywhere regarding this issue. [2010-05-24 13:46:10] codeslinger at compsalot dot com In Summary: As Reported by Multiple People Windows XP (32 bit) PHP 5.2.4 Fails Windows XP (32 bit) PHP 5.2.5 Works Windows 2000 (32 bit) PHP 5.2.5 Works Windows XP (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.11 Fails Windows 2003 (?? bit) PHP 5.2.12 Fails Windows 2003 (?? bit) PHP 5.2.13 Fails Ubuntu 8 (32bit) PHP 5.2.4 Fails Ubuntu 8 (32bit) PHP 5.2.9 (custom build) Works Ubuntu 9 (64bit) PHP 5.2.10 Works Mandriva 2008 (32bit 64bit) PHP 5.2.4 Works Mandriva 2008 (32bit 64bit) Unpatched PHP 5.2.5 Fails This bug has been reported by multiple people. The above list is the combination of my own testing plus what I found reported by other people. The windows oses are all using the STOCK BUILD as provided by php.net It is very important to understand that the specific values which fail are highly variable. A specific value which fails on one os/php version does not necessarily fail on a different combination of os+php, but a different value will fail instead. It is also important to realize that given the obscurity and variability of this bug, just because a particular version of php is reported as working, does not guarantee that the bug does not exist, it only says that so far no one has reported encountering a specific value which triggers this bug. All of the following are thought to influence the specific behavior and reproducibility of this bug. The number of cpu bits The operating system The specific version of php The compiler flags that were used to build php The precision setting for php The format specifier/precision in an sprintf statement sprintf versus implied (string) conversion It is also possible that the floating point hardware could have an influence on the reproducibility of this bug. Since the WORK-AROUND did not work for John, it would appear that we still have a problem which needs to be solved. [2010-05-24 03:17:36] john dot smith dot 1964 at gmail dot com This problem isn't fixed for us by adding ini_set(precision, 16);. Our PHP install is stock off the website (5.2.4 and 5.2.13, for instance) and our box runs Windows 2003. [2010-05-24 02:18:46] paj...@php.net . [2010-05-24 02:04:27] codeslinger at compsalot dot com Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Bogus Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: Pajoye Please take a look at #43487 this appears to be where the Mandriva Devs landed their change. Quote: as peroyvind found, the miscompilation is inside Zend/zend_strtod.c, and -no-ftree-vrp workaround the bug. Unfortunately that change does not appear to have done the trick. This thing is dang hard to reproduce, short of running through every possible 58 digit number, or getting really lucky with random numbers, I can't see how to reliably test this. Previous Comments: [2010-05-24 14:14:53] paj...@php.net And please use latest 5.3 or 5.2, from our downloads (only). [2010-05-24 14:04:53] codeslinger at compsalot dot com P.S. Please note that in my own testing I have verified that the presence or absence of the xdebug and zend debug extensions do not alter the behavior of this bug, this was verified on Windows. Also note how for instance 5.2.4 fails on Windows and on Ubuntu but works on Mandriva (or at least was not found to fail on Mandriva). Also I can tell you from my own testing that the specific values which fail on Windows are very different from the specific values which fail on Unbuntu, when tested on the same computer. The only thing which can be said with some level of confidence is that all of the failures involve numbers with the digit 9 in them. Since these are 58? digit numbers and only a very few specific values fail, the potential to NOT see a failure is huge. [2010-05-24 13:59:45] paj...@php.net Please read my last comment and provide the info I asked there. Without that, there is not a chance to get anywhere regarding this issue. [2010-05-24 13:46:10] codeslinger at compsalot dot com In Summary: As Reported by Multiple People Windows XP (32 bit) PHP 5.2.4 Fails Windows XP (32 bit) PHP 5.2.5 Works Windows 2000 (32 bit) PHP 5.2.5 Works Windows XP (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.9 Fails Windows 2000 (32 bit) PHP 5.2.11 Fails Windows 2003 (?? bit) PHP 5.2.12 Fails Windows 2003 (?? bit) PHP 5.2.13 Fails Ubuntu 8 (32bit) PHP 5.2.4 Fails Ubuntu 8 (32bit) PHP 5.2.9 (custom build) Works Ubuntu 9 (64bit) PHP 5.2.10 Works Mandriva 2008 (32bit 64bit) PHP 5.2.4 Works Mandriva 2008 (32bit 64bit) Unpatched PHP 5.2.5 Fails This bug has been reported by multiple people. The above list is the combination of my own testing plus what I found reported by other people. The windows oses are all using the STOCK BUILD as provided by php.net It is very important to understand that the specific values which fail are highly variable. A specific value which fails on one os/php version does not necessarily fail on a different combination of os+php, but a different value will fail instead. It is also important to realize that given the obscurity and variability of this bug, just because a particular version of php is reported as working, does not guarantee that the bug does not exist, it only says that so far no one has reported encountering a specific value which triggers this bug. All of the following are thought to influence the specific behavior and reproducibility of this bug. The number of cpu bits The operating system The specific version of php The compiler flags that were used to build php The precision setting for php The format specifier/precision in an sprintf statement sprintf versus implied (string) conversion It is also possible that the floating point hardware could have an influence on the reproducibility of this bug. Since the WORK-AROUND did not work for John, it would appear that we still have a problem which needs to be solved. [2010-05-24 03:17:36] john dot smith dot 1964 at gmail dot com This problem isn't fixed for us by adding ini_set(precision, 16);. Our PHP install is stock off the website (5.2.4 and 5.2.13, for instance) and our box runs Windows 2003. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: In response to johan...@php.net above. Let me just very politely reiterate that I originally encountered this bug on the STOCK WINDOWS BUILD from php.net, therefore to dismiss this bug because it is ubuntu specific is not a valid reason. This bug is very hard to reproduce, but none-the-less occurs far too frequently under real-world conditions. The actual values required to reproduce this bug appear to vary depending on what version of php is being tested and what os/cpu it is running on. Given the randomly variant nature of this problem, I suspect that the only way you could properly test this bug and have confidence in the outcome is if you loop through every possible floating point value and convert it to a string. You would also need to do this on multiple platforms. Of course that would probably take a few years... so perhaps code inspection and some alerts would be a better option. Testing numbers selected at random is not likely to succeed, the number space is too large and you can't account for possible biases in the random number generator -- perhaps it only returns numbers which php sees as valid. Other people have reported this bug, see for instance #49764 and also the above comments about Mandriva Devs creating a patch to fix this bug. I do not regard millions of Ubuntu users as unimportant, or irrelevant. The severity of the consequences of this bug ought to be sufficient justification for a little bit of extra effort being expended -- even if the problem had been caused by ubuntu patches which it wasn't. People who are affected by this bug may not always realize what the problem is. This bug is probably underreported by quite a bit. Also as pointed out earlier the majority of php web pages do not do very much floating point math and therefore would not encounter this bug. In the discussion above it appears that there is some obscure case for which the number conversion is off-by-one. Pajoye thinks he has a fix. The fact that this afflicts Financial Transactions -- as reported by multiple people -- makes this a gravely serious bug... so why then is it so exasperatingly difficult to get the php dev community to take this problem seriously? In case you are wondering why it took me so long to respond to Johannes, it's because I had to cool off first I really am trying not to be overwrought, honest, ;-) Previous Comments: [2010-04-14 04:37:08] john dot smith dot 1964 at gmail dot com The folk at Mandriva saw the same problem, figured it out and submitted a patch to PHP. I'm confused, because we're certainly still seeing the problem: https://qa.mandriva.com/show_bug.cgi?id=37171 In PHP on Mandriva 2008, some float to string conversions return 0.0: !! In critical software, this can lead to major loss of data or inconsistant results. [2010-04-13 03:36:47] john dot smith dot 1964 at gmail dot com I am seeing this bug consistently on standard Windows builds such as 5.2.4 and 5.2.13. Our Server is: Windows NT 5.2 build 3790 Sample code is simple: ? echo round(1451,2); ? On 5.2.4 it will result in 1450.:0 every time. On 5.2.4, other such *funny* values are 1701,1821,1951,2091,2101,2111,2121,2341,2351... On 5.2.13,the numbers 1700 and 1900 consistently return colon-ized results. This is a especially problematic, because 1700 and 1900 occur more frequently in our eCommerce app! This issue is a real problem for us. It has been touched on (but not solved) in at least Bugs 46376, 47716, 47304 and 47418. [2010-03-27 14:19:44] johan...@php.net You are mentioned this version information: php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies This version is very different from the versions we provide. a) Ubuntu adds some custom patches b) Suhosin does major changes to the engine c) Xdebug as well as Zend Debugger do changes to our executor unit. All these components aren't supported here. [2010-03-27 12:50:58] codeslinger at compsalot dot com One
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: Yipee!!! at least I have finally found a work-around that I can live with!!! You can close this bug now. The Mandriva Devs seem to think that this is actually a GCC bug and that it is Dependant on the build flags used. You can read about it here. https://qa.mandriva.com/show_bug.cgi?id=37171 Thanks to John (above) for the link. A lot more reading/searching of this WELL KNOWN ISSUE finally lead me to here: http://www.mysqlperformanceblog.com/2008/01/10/php-vs-bigint-vs-float-conversion-caveat/ and here: http://www.farad.com.au/source_code/php/setting_floating_point_precision_src.php To cut to the chase, the actual work-around is to change the precision. This solution was hinted at by my simplefail.php program (test option 20), but I was unaware of an ini setting that is available for this. The solution to all of this madness and it is very mad indeed... is to add the following in your php program. ini_set(precision, 16); End of Problem End of Bug... Like Good Day Eh? Previous Comments: [2010-05-23 14:42:13] paj...@php.net There is no need to write a novel about this possible issue. Please ask the Mandriva guys to actually report a bug here (in this report for example), post their patch(es), a reproduce script with a description of their architecture (compiler, compiler versions, OS, etc.). Everything else are unnecessary information. Now, what Johannes said is still valid: - we don't support custom version of PHP (aka patched) - that includes suhoshin patch - Debugger/optimizer (zend, xdebug, etc.) has to be removed to reproduce a problem. Thanks for your feedback. [2010-05-23 09:38:47] codeslinger at compsalot dot com In response to johan...@php.net above. Let me just very politely reiterate that I originally encountered this bug on the STOCK WINDOWS BUILD from php.net, therefore to dismiss this bug because it is ubuntu specific is not a valid reason. This bug is very hard to reproduce, but none-the-less occurs far too frequently under real-world conditions. The actual values required to reproduce this bug appear to vary depending on what version of php is being tested and what os/cpu it is running on. Given the randomly variant nature of this problem, I suspect that the only way you could properly test this bug and have confidence in the outcome is if you loop through every possible floating point value and convert it to a string. You would also need to do this on multiple platforms. Of course that would probably take a few years... so perhaps code inspection and some alerts would be a better option. Testing numbers selected at random is not likely to succeed, the number space is too large and you can't account for possible biases in the random number generator -- perhaps it only returns numbers which php sees as valid. Other people have reported this bug, see for instance #49764 and also the above comments about Mandriva Devs creating a patch to fix this bug. I do not regard millions of Ubuntu users as unimportant, or irrelevant. The severity of the consequences of this bug ought to be sufficient justification for a little bit of extra effort being expended -- even if the problem had been caused by ubuntu patches which it wasn't. People who are affected by this bug may not always realize what the problem is. This bug is probably underreported by quite a bit. Also as pointed out earlier the majority of php web pages do not do very much floating point math and therefore would not encounter this bug. In the discussion above it appears that there is some obscure case for which the number conversion is off-by-one. Pajoye thinks he has a fix. The fact that this afflicts Financial Transactions -- as reported by multiple people -- makes this a gravely serious bug... so why then is it so exasperatingly difficult to get the php dev community to take this problem seriously? In case you are wondering why it took me so long to respond to Johannes, it's because I had to cool off first I really am trying not to be overwrought, honest, ;-) [2010-04-14 04:37:08] john dot smith dot 1964 at gmail dot com The folk at Mandriva saw the same problem, figured it out and submitted a patch to PHP. I'm confused, because we're certainly still seeing the problem: https://qa.mandriva.com/show_bug.cgi?id
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. Previous Comments: [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: One further note, in the repro above, it has to be exactly 16 nines. by adding or removing a 9, it does not fail. Also, as far as I know, all of the failures have been on 32bit Intel cpu's. This probably will not fail on a 64bit cpu. Previous Comments: [2010-03-27 12:22:12] codeslinger at compsalot dot com well, it's hard to prove a negative. but I have run a bunch of tests on the Linux snapshot and it appears to be working fine. A VERY BIG THANKYOU I did not find any windows snapshots, the latest is 5.2.13 from Feb 24. based on the symptoms, my initial assumption was that this was caused by some kind of array corruption, this turned out to be wrong. the actual repro can be boiled down to one line... :-) echo (string) (double) -0.0; With the caveat that there are other values which also trigger this. [2010-03-26 21:37:12] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. Previous Comments: [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex and proprietary and the data is confidential and it uses several external libraries. The other program generates a Koch Snowflake (a type of graphics fractal). It is small and has no required dependencies and I am happy to make it's source code available. Both fail with the same or similar math errors but the behavior is not identical. The billing system *appears* to run fine on Windows PHP 5.2.5 (standard build as provided by php.net). The billing system is in daily use and no errors have been reported... so far... At one point it was decided to upgrade to PHP 5.2.9 (standard build from php.net). The billing system passed
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. Previous Comments: [2010-03-26 09:30:30] paj...@php.net 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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: Thank You for the response. This program executes thousands of identical loops it performs a number format conversion on each of those thousands of numbers in it's array. Out of all of those thousands of identical conversions about 4 of them will produce an invalid result. for this specific program, if I skip the array_merge (see $Nest) then the bug does not occur. Every time I make a change to the loops etc. the behavior changes, even to where the bug is not triggered. I have already simplified this program quite a bit and the result was that it now fails at a totally different array index then when I first observed the problem. The trigger is very finicky. XP is not a factor here, even though the original problem was found on XP, I am running this Snowflake program on Ubuntu Linux. converting a number to a string should never result in that string containing a non-numeric character. I can try to reduce this program further, but really and truly, it is hard to trigger this -- but once triggered it is totally consistent and repeatable. Previous Comments: [2010-03-26 10:11:25] paj...@php.net Btw, it could be due to bad initialized data as well (as you experience it on unix as well). Can you try to run your script under valgrind too? [2010-03-26 09:54:33] paj...@php.net It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net 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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: quote: Btw, it could be due to bad initialized data as well I don't understand the question/statement. The program generates all of it's data. If you look near the bottom of pov.pco.php you will see the following line: echo FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n; If you set a breakpoint there in a php debugger and examine the vaules you will see that that array contains a float of 0.1 and that the string it was converted to is 0.0: Previous Comments: [2010-03-26 10:17:47] codeslinger at compsalot dot com Thank You for the response. This program executes thousands of identical loops it performs a number format conversion on each of those thousands of numbers in it's array. Out of all of those thousands of identical conversions about 4 of them will produce an invalid result. for this specific program, if I skip the array_merge (see $Nest) then the bug does not occur. Every time I make a change to the loops etc. the behavior changes, even to where the bug is not triggered. I have already simplified this program quite a bit and the result was that it now fails at a totally different array index then when I first observed the problem. The trigger is very finicky. XP is not a factor here, even though the original problem was found on XP, I am running this Snowflake program on Ubuntu Linux. converting a number to a string should never result in that string containing a non-numeric character. I can try to reduce this program further, but really and truly, it is hard to trigger this -- but once triggered it is totally consistent and repeatable. [2010-03-26 10:11:25] paj...@php.net Btw, it could be due to bad initialized data as well (as you experience it on unix as well). Can you try to run your script under valgrind too? [2010-03-26 09:54:33] paj...@php.net It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net 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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1
ID: 51396
Comment by: codeslinger at compsalot dot com
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
Assigned To: aharvey
New Comment:
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is 0.0: not that
php gives any kind of error message.
Previous Comments:
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n;
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is 0.0:
[2010-03-26 10:17:47] codeslinger at compsalot dot com
Thank You for the response.
This program executes thousands of identical loops
it performs a number format conversion on each of those thousands of
numbers in it's array.
Out of all of those thousands of identical conversions about 4 of them
will produce an invalid result.
for this specific program, if I skip the array_merge (see $Nest) then
the bug does not occur.
Every time I make a change to the loops etc. the behavior changes, even
to where the bug is not triggered. I have already simplified this
program quite a bit and the result was that it now fails at a totally
different array index then when I first observed the problem. The
trigger is very finicky.
XP is not a factor here, even though the original problem was found on
XP, I am running this Snowflake program on Ubuntu Linux.
converting a number to a string should never result in that string
containing a non-numeric character.
I can try to reduce this program further, but really and truly, it is
hard to trigger this -- but once triggered it is totally consistent and
repeatable.
[2010-03-26 10:11:25] paj...@php.net
Btw, it could be due to bad initialized data as well (as you experience
it on unix as well).
Can you try to run your script under valgrind too?
[2010-03-26 09:54:33] paj...@php.net
It looks to me in a bug at the number formatting in the Windows API (not
php dependent). Other users met this problem on old XP systems. You
could reproduce it using number_format only. Or maybe only with a single
printf function.
Can you try using another windows box or using 5.3.2-vc9 builds?
Btw, it is not about bad or good attitude but about having something we
can actually use to help you. I can understand your worries after having
spent hours to debug this problem, but we will still use a small script
to debug this problem, if any.
[2010-03-26 09:40:23] codeslinger at compsalot dot com
did you even LOOOKK at the script that I provided?
it is not that complicated. a few loops and some array allocations.
previous attempts to reduce this to anything simpler have been
unsuccessful.
this is exactly the attitude that causes me to be overwrought.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51396
--
Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1
ID: 51396
Comment by: codeslinger at compsalot dot com
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
New Comment:
it's still not 20 lines... it never will be but I found one
surprising thing, if I save the array to disk and read it back in I
still get the same failure.
so essentially the snowflake is a Psudo-RNG and that's why trying to
simplify it does not work, because it has to be able to generate all of
those different numbers. but once we have the set of numbers the
generator becomes irrelevant.
Try this program:
http://www.compsalot.com/phpbug/kochsnowflake/simplefail/
weirdly, every failure is a -0.1
but there are two things that I'm concerned about.
1) It seems unlikely that the billing program was only failing on that
amount, it is a pretty unusual amount. Not one I'd normally expect to
see and there were a lot of failures.
2) I'm concerned about the limitations of the detection method. I am
only finding bad values because they have a colon in the string. I am
not currently checking for mathematical correctness. We may not be
seeing the whole story, there could be a lot more bad values that just
are not blatant enough to be observed.
But at least this should give you the starting point that you are asking
for. The program is reduced to reading a file from disk and checking
each number to see if it's valid. can't get any simpler than that.
Of course if the corruption is happening when the value is created,
looking at them after the fact may still not help much. But when I look
at these values in the eclipse zend debugger, they look normal enough
despite the fact that they can't be properly converted.
--
The data files are as follows:
rawpairs.txt is a 6.5meg file and contains both good and bad values,
you don't need this file unless you are trying to validate the
serialization. This is from a single run of the snowflake, $Nest = 3;
$Depth = 5;
The following were extracted from the raw data.
onepair.txt contains a single failure item
selectpairs.txt contains 8 failures which were from a single run of
snowflake
manypairs.txt contains about 40 failures which are the result of
multiple runs of the snowflake using different Nest Depth parameters.
Previous Comments:
[2010-03-26 11:14:13] paj...@php.net
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is 0.0: not that
php gives any kind of error message.
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n;
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is 0.0:
[2010-03-26 10:17:47] codeslinger at compsalot dot com
Thank You for the response.
This program executes thousands of identical loops
it performs a number format conversion on each of those thousands of
numbers in it's array.
Out of all of those thousands of identical conversions about 4 of them
will produce an invalid result.
for this specific program, if I skip the array_merge (see $Nest) then
the bug does not occur.
Every time I make a change to the loops etc. the behavior changes, even
to where the bug is not triggered. I have already simplified this
program quite a bit and the result was that it now fails at a totally
different array index then when I first observed the problem
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP Previous Comments: [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. [2010-03-26 16:26:05] ras...@php.net I ran your simplefail.php on all 4 data files. Never saw the failure case. Then I took just the huge rawpairs.txt file (had to increase the memory_limit) and modified your program slightly to do: for($i=0;$i10;$i++) ConvertData($data); and ran that, which took quite a while. Still no failures. You are still the only person who has ever reported these weird : characters showing up, and you have yet to produce any sort of code that reproduces it for someone else. We'll keep trying, but something that happens for 1 person out of millions is suspicious. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. Previous Comments: [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396edit=1
[PHP-BUG] Bug #51396 [NEW]: Math is Unreliable
From: Operating system: any PHP version: Irrelevant Package: Math related Bug Type: Bug Bug description:Math is Unreliable Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex and proprietary and the data is confidential and it uses several external libraries. The other program generates a Koch Snowflake (a type of graphics fractal). It is small and has no required dependencies and I am happy to make it's source code available. Both fail with the same or similar math errors but the behavior is not identical. The billing system *appears* to run fine on Windows PHP 5.2.5 (standard build as provided by php.net). The billing system is in daily use and no errors have been reported... so far... At one point it was decided to upgrade to PHP 5.2.9 (standard build from php.net). The billing system passed the preliminary testing with dummy data and the php upgrade was deployed to the field. Result: Can you spell NIGHTMARE?!!! I knew you could... Many instances of invalid statements being created. The math errors were repeatable. We are talking simple arithmetic about 90 percent of it is just adding, with a few multiplications. This was entered as bug #47716 Everyone was downgraded back to php 5.2.5 and the bug report was blown off. I also confirmed that the bug existed in 5.2.11 I assumed that the bug did not exist in 5.2.5 An attempt was made to test 3.x but that was impossible because the billing system requires various libraries which are not available for version 3 of php. And that is where things have sat until now. New program, Koch Snowflake generator. I'm doing some experiments with 3d graphics. This was written as a study in how to do it. I ran into exactly the same math -- string conversion bug, that the billing system ran into. But the Koch Snowflake program Fails on Ubuntu Linux with php 5.2.4!!! What triggers this bug is a very complex unpredictable sequence of events. And yet the failure is totally repeatable. Being a fractal, it has an outer loop of iterations which determine the complexity of the object. When I run 4 outer loops the program works fine, when I run 6 outer loops the program also works fine -- thus proving that it is not running out of memory. But when I run 5 outer loops the program fails and it always fails at item 7747. But
#50526 [NEW]: stream_stat needs Context
From: codeslinger at compsalot dot com Operating system: any PHP version: 5.2.12 PHP Bug Type: Feature/Change Request Bug description: stream_stat needs Context Description: Feature Request: the stream wrapper functions are *totally awesome* :-) !!! but the stat family of functions is limited by the lack of a context param. For instance I need to be able to provide a user name and password for a particular connection. for opendir mkdir fopen etc. I am able to pass a context with that info and everything works. But then when I try to do a stat or fstat it fails because there is no way to pass the $context. Thank you for making PHP such a fantastic programming language! Reproduce code: --- --- From manual page: streamwrapper.stream-stat#Description --- Actual result: -- also see related Bug #42965 copy() should support context parameters for URLs -- Edit bug report at http://bugs.php.net/?id=50526edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50526r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50526r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50526r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50526r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50526r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50526r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50526r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50526r=needscript Try newer version: http://bugs.php.net/fix.php?id=50526r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50526r=support Expected behavior: http://bugs.php.net/fix.php?id=50526r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50526r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50526r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50526r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50526r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50526r=dst IIS Stability: http://bugs.php.net/fix.php?id=50526r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50526r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50526r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50526r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50526r=mysqlcfg
#15101 [Com]: eval() in other context
ID: 15101 Comment by: codeslinger at compsalot dot com Reported By: tom dot polak at post dot sk Status: Open Bug Type: Feature/Change Request Operating System: Solaris PHP Version: 4.1.0 New Comment: this bug is really old, it can be closed now... as FIXED. php now has at least two ways that you can accomplish this. 1) in php 5.3+ you can create a name space and do the eval inside of it. 2) On windows you can use ActiveScript PHP and it will behave exactly as you described for the behavior of SQLWindows. or you could just exec or even popen an instance of php... Previous Comments: [2002-01-18 09:45:05] tom dot polak at post dot sk Hello, my request is to improve function eval() to be possible evaluate given string in other than current context. In SQLWindows, where I have programming before, I have this feature and was very useful. It means, that on the some place in script we save context to be used for evaluate and receive some resource variable to identify it. Lately, we can call eval() with this additional parameter to be able evaluate given string in previously saved context. In SQLWindows I have used this to bind variables into dynamicaly generated SQL statements, because they were generated inside some functions library, where the current local variables are not in scope. If it is not clear, I can give you more specification. If you do not realize this feature, send me info, to be not waiting in my project on it. Looking forward to your answer. Best regards, Tomas Polak mailto:tom.po...@post.sk -- Edit this bug report at http://bugs.php.net/?id=15101edit=1
#48219 [Com]: POST data is not decoded, according to Content-Transfer-Encoding
ID: 48219 Comment by: codeslinger at compsalot dot com Reported By: carsten_sttgt at gmx dot de Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.*, 6CVS (2009-05-09) New Comment: Well, I mostly deal with email, especially including webmail. and as far as I can see, nearly all attachments are base64 encoded. In fact it is hard to find anything that isn't, unless it's plain text. So, I guess I was a little bit confused about the difference between HTTP uploads and email uploads, since they both use MIME and typically they both contain web pages. With regard to this feature request. I would really like for php to make the MIME Header info available. That way we can easily do our own decoding as long as we have access to the info that tells us what needs to be decoded, currently we don't, at least not with out kludge hacks, and that makes it hard to do something which should be simple. Previous Comments: [2009-11-19 23:55:12] avalon73 at caerleon dot us RFC 2616 section 3.2.7 itself says nothing about the use of Content-Transfer-Encoding (CTE). RFCs 1867 and 2388 both mention the possibility of the multipart/form-data MIME type being used with email as a transport as well as HTTP. The CTE header and the base64 and quoted-printable encodings were included in MIME specifically for moving 8-bit data over 7-bit transport protocols, which included basic (non-enhanced) SMTP at the time of its creation (and still does, if you adhere strictly to the RFCs). The other standard encodings defined for the CTE header (7bit, 8bit, and binary) imply no content encoding at all. HTTP is and has always been an 8-bit clean transport protocol. Because of that, it has no need for any encodings designed to move 8-bit data over a 7-bit protocol. In fact, the use of such encodings would only needlessly add bulk to the data being transferred. If no such transformation is necessary, the addition of the CTE header is also not necessary. Section 19.4.5 of RFC 2616 would seem to merely codify this fact, effectively forbidding the use of CTE over HTTP. [2009-11-19 23:00:39] carsten_sttgt at gmx dot de Has anyone noticed this? http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5 Sure, but in rfc2616-sec3.html#sec3.7.2 you can read, that especially multipart/form-data is defined in RFC1867 (RFC2388). And there you can read about the content-transfer-encoding. Regards, Carsten [2009-11-19 20:59:16] avalon73 at caerleon dot us Has anyone noticed this? http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5 RFC 2616 is the one for HTTP 1.1, and the first paragraph reads as such: --- HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE (quoted-printable or base64) encoding prior to delivering the response message to an HTTP client. --- Perhaps that's why PHP hasn't supported it, and why no browser in the real world (that I know of... I could be mistaken) ever sends base-64 or quoted-printable encoded multipart/form-data parts? [2009-11-18 08:23:46] codeslinger at compsalot dot com this also afflicts Base64 encoding which is a massively prevalent method for binary transfers I am really surprised to encounter this *bug* It means that everything php is doing with regard to saving/moving uploaded files is wasted/useless effort. Since the content transfer type is not even accessible, we must instead do our own parsing of the raw post data. How can that be by design??? [2009-05-15 00:14:44] carsten_sttgt at gmx dot de After a quick view to rfc1867.c, I found a lot of: | #if HAVE_MBSTRING !defined(COMPILE_DL_MBSTRING) So I guess a correct behavior, according to rfc2616/rfc1867, is only possible and working, if you have the mbstring extension, and if this is not a shared extension. (why does this not work with a shared extension?) (can't test this, because this extension is always shared in my installations.) It's like bug #37860: A HTTP UA is sending such a valid POST request and PHP is answering with a status 200. And both, browser an script, must assume all is ok. Instead the data is garbled. In contrast to bug #37860, it's not defined to return a status 415, (but maybe the best solution for now?). In case of bug #37860, the return status 415 is defined for such situation. But PHP is also not doing this :-/ Also a problem, if all parts are thinking the POST request is OK. Regards, Carsten
#48219 [Com]: POST data is not decoded, according to Content-Transfer-Encoding
ID: 48219 Comment by: codeslinger at compsalot dot com Reported By: carsten_sttgt at gmx dot de Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.*, 6CVS (2009-05-09) New Comment: this also afflicts Base64 encoding which is a massively prevalent method for binary transfers I am really surprised to encounter this *bug* It means that everything php is doing with regard to saving/moving uploaded files is wasted/useless effort. Since the content transfer type is not even accessible, we must instead do our own parsing of the raw post data. How can that be by design??? Previous Comments: [2009-05-15 00:14:44] carsten_sttgt at gmx dot de After a quick view to rfc1867.c, I found a lot of: | #if HAVE_MBSTRING !defined(COMPILE_DL_MBSTRING) So I guess a correct behavior, according to rfc2616/rfc1867, is only possible and working, if you have the mbstring extension, and if this is not a shared extension. (why does this not work with a shared extension?) (can't test this, because this extension is always shared in my installations.) It's like bug #37860: A HTTP UA is sending such a valid POST request and PHP is answering with a status 200. And both, browser an script, must assume all is ok. Instead the data is garbled. In contrast to bug #37860, it's not defined to return a status 415, (but maybe the best solution for now?). In case of bug #37860, the return status 415 is defined for such situation. But PHP is also not doing this :-/ Also a problem, if all parts are thinking the POST request is OK. Regards, Carsten [2009-05-10 19:15:16] carsten_sttgt at gmx dot de And this is (I think :) related also to bug #37860 Yes, it's similar. BTW. I think bug #37860 is a feature request and also a bug. - Feature: It would be nice, if PHP is decoding the data if the coding is known (see rfc2616-sec3.5/-sec14.1. e.g. if the gzip-extension is loaded and Content-Encoding: gzip is set in the request - Bug: if PHP can't/won't do this, it should raise/return a HTTP status code of 415. (See rfc2616-sec14.11) Unfortunately this is a feature request so reclassifying as such. That's really something I was unsure about. See rfc2616-sec3.5. In general: | an HTTP user agent SHOULD follow the same or similar behavior | as a MIME user agent would upon receipt of a multipart type. | The MIME header fields within each body-part of a multipart | message- body do not have any significance to HTTP beyond that | defined by their MIME semantics. Well, a MIME user agent must decode such data. Because of the should in this statement, it /can/ be a feature request (but should is more restrictive than a may / optional.). But same section rfc2616-sec3.5: Note: The multipart/form-data type has been specifically defined for carrying form data suitable for processing via the POST request method, as described in RFC 1867 [15]. And in rfc1867 (or the newer rfc2388), Content-Transfer-Encoding is explicit part of the rfc. So I think a HTTP software should know and handle Content-Transfer-Encoding. Well, Perls' CGI.pm also is not doing this ;-) BTW: In difference to the Content-Encoding, I can't see the Content-Transfer-Encoding in the script. So that can be really a problem. But using a Content-Transfer-Encoding is not usual (or is it not usual, because Perl/PHP can't handle this?) btw. Fastest way to get this implemented is by providing a patch. :) Yeah, if my C would be better... ;-) [2009-05-10 17:02:30] j...@php.net btw. Fastest way to get this implemented is by providing a patch. :) [2009-05-10 17:01:57] j...@php.net Unfortunately this is a feature request so reclassifying as such. And this is (I think :) related also to bug #37860 and maybe some others I couldn't find. :) [2009-05-10 10:49:28] carsten_sttgt at gmx dot de Description: Hallo, In a HTTP POST request and Content-Type multipart/form-data, each part can have a Content-Transfer-Encoding, which is defined in RFC2045. (See also HTML 4.01-sec17.13.4.2) PHP only works with 7bit, 8bit and binary, because with these values, the data is not transformed. With base64 or quoted-printabled, the data is transformed (encoded), and PHP should decode it (see also rfc2616-sec3.7.2 / rfc1867-sec3.3). Just test the above example from RFC2388-sec4.5. That's also a problem, if you upload a file with such a transfer encoding. After move_uploaded_files, the content of such file is not really what you aspect. And in a script, which receives such data, I don't see (can't know
#47716 [Bgs]: Invalid/Corrupt Math Convert string to float
ID: 47716
User updated by: codeslinger at compsalot dot com
Reported By: codeslinger at compsalot dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: windows 2000
PHP Version: 5.2.9
New Comment:
This is a copy of the comment that I put into Bug #47304 That bug has
now been closed due to lack of activity. So, we now have multiple
closed bugs, no fixes in sight, no further dev activity expected, and a
very serious problem remains.
---
Hi pajoye,
thank you for the response to bug #47716
you requested that future replies be here.
The interesting thing is that when you did a setlocale you got a
result
back... but when I did it all I get is an empty string, I wondered
about this at the time that I entered the bug but did not mention it
because I figured the 18:0 vs 19.00 was sufficient.
and yes, as it states in that bug, the problem only occurs when a
large
complex program using lots of memory is running and then within that
context you run the repro. if you just do the repro script by itself
with nothing else going on then it works just fine.
$arrMsgs[] = Locale = .setlocale(LC_ALL, english-usa);
[0] = Locale =
I will give 5.3 a try and see what happens.
Environment: For the testing, I am actually running windows 2000 in a
vmware box under Ubuntu on a Pentium M.
-
P.S. my program has some dependencies on PECL libs, it turns out not
to be possible for me to run 5.3 at this time.
Previous Comments:
[2009-03-20 16:04:34] paj...@php.net
Please reply in #47304 (duplicated).
[2009-03-20 15:57:31] paj...@php.net
I'm not sure what's wrong.
Here is what I get:
Windows 2008 (latest SP):
Array
(
[0] = Locale = English_United States.1252
[1] = memory_get_peak_usage(true) = 262144
[2] = memory_get_peak_usage(false) = 58240
[3] = memory_get_usage(true) = 262144
[4] = memory_get_usage(false) = 57240
[5] = (float)19.00 = 19
[6] = (float)'19.00' = 19
[7] = round('19.00', 2) = 19
)
Windows 2003 (latest SP):
Array
(
[0] = Locale = English_United States.1252
[1] = memory_get_peak_usage(true) = 262144
[2] = memory_get_peak_usage(false) = 56152
[3] = memory_get_usage(true) = 262144
[4] = memory_get_usage(false) = 56024
[5] = (float)19.00 = 19
[6] = (float)'19.00' = 19
[7] = round('19.00', 2) = 19
)
Windows XP sp2:
Array
(
[0] = Locale = English_United States.1252
[1] = memory_get_peak_usage(true) = 262144
[2] = memory_get_peak_usage(false) = 57112
[3] = memory_get_usage(true) = 262144
[4] = memory_get_usage(false) = 56112
[5] = (float)19.00 = 19
[6] = (float)'19.00' = 19
[7] = round('19.00', 2) = 19
)
[2009-03-20 15:40:32] codeslinger at compsalot dot com
in case it wasn't clear from the description above, this is using the
CLI version of php.
also unlike a number of other bugs that I have read. Adding and
removing various lines of code -- which I did quite a bit of while
isolating this problem, plus adding a planned revision to the code --
had no effect on the result, the bug was totally repeatable.
This was using the official php windows binary, not one that I
compiled. The only difference between the working and not working
versions of the program are the php version.
How is it possible to convert a string to a float and have the result
contain a colon character???
[2009-03-19 12:11:23] codeslinger at compsalot dot com
Description:
It is with great hesitancy that I enter this bug, because I am not able
to produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9 and also tested with 5.2.9-1
both with and without xdebug enabled.
The math is bad, the calculations are incorrect. Below is a program
that displays this problem, but it does not fail when run stand-alone,
this program only fails when run inside of the billing program's context
where it is calculating the statement balances.
The billing program of course does a billion things before it gets to
this point. But at that point the math behavior of PHP is corrupt.
Wrong math results are the only visible sign of the problem, the program
runs to completion and prints the statements etc.
The program reads the numbers from a database as strings and converts
them to floats to do the totals. This is not a case of loss of
precision, as I said the program runs fine on 5.2.5. But sprintf will
convert 19.00 to = 18:0
Note
#47717 [Com]: PHP / Curl issue
ID: 47717
Comment by: codeslinger at compsalot dot com
Reported By: ray_kimsey at ncsu dot edu
Status: Open
Bug Type: *General Issues
Operating System: RHEL 5.3
PHP Version: 5.2.9
New Comment:
in bug #47616 the problem turned out to be incorrect passing of the
parameters. This bug may be related.
Previous Comments:
[2009-03-19 13:28:19] ray_kimsey at ncsu dot edu
Description:
Compiled current production PHP 5.2.9 (and with CVS version
php5.2-200903181530) with Curl 7.19.4 (x86_64) using code below fails:
Compiled PHP 5.2.6 against Curl 7.19.4 works as expected.
Compiled php5.2-200903181530 compiled against RHEL curl 7.15.5 (x86_64)
works as expected.
Reproduce code:
---
?php
$ch = curl_init();
//curl_setopt($ch, CURLOPT_URL, 'http://www.google.com/');
curl_setopt($ch, CURLOPT_URL, 'http://newton.ces.ncsu.edu/');
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
if (curl_exec($ch) === false) {
echo 'Curl error: ' . curl_error($ch) . \n;
}
curl_close($ch);
?
Expected result:
$ php t.php
* About to connect() to newton.ces.ncsu.edu port 80
* Trying 152.1.215.211... * connected
* Connected to newton.ces.ncsu.edu (152.1.215.211) port 80
GET / HTTP/1.1
Host: newton.ces.ncsu.edu
Accept: */*
HTTP/1.1 200 OK
Date: Thu, 19 Mar 2009 13:20:25 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8j DAV/2
PHP/5.2.10-dev SVN/1.5.4
Last-Modified: Mon, 23 Jan 2006 12:53:15 GMT
ETag: 10486c8-3d-40b061d3ba4c0
Accept-Ranges: bytes
Content-Length: 61
Content-Type: text/html
* Connection #0 to host newton.ces.ncsu.edu left intact
* Closing connection #0
Actual result:
--
$php t.php
* url malformed
Curl error: url malformed
if you exchange newton.ces.ncsu.edu with www.google.com you get:
php t.php
* Input domain encoded as `UTF-8'
* getaddrinfo(3) failed for xn--6l4d:80
* Couldn't resolve host ?'
* Closing connection #0
Curl error: Couldn't resolve host ?'
--
Edit this bug report at http://bugs.php.net/?id=47717edit=1
#47716 [Com]: Invalid/Corrupt Math Convert string to float
ID: 47716
Comment by: codeslinger at compsalot dot com
Reported By: codeslinger at compsalot dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: windows 2000
PHP Version: 5.2.9
New Comment:
in case it wasn't clear from the description above, this is using the
CLI version of php.
also unlike a number of other bugs that I have read. Adding and
removing various lines of code -- which I did quite a bit of while
isolating this problem, plus adding a planned revision to the code --
had no effect on the result, the bug was totally repeatable.
This was using the official php windows binary, not one that I
compiled. The only difference between the working and not working
versions of the program are the php version.
How is it possible to convert a string to a float and have the result
contain a colon character???
Previous Comments:
[2009-03-19 12:11:23] codeslinger at compsalot dot com
Description:
It is with great hesitancy that I enter this bug, because I am not able
to produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9 and also tested with 5.2.9-1
both with and without xdebug enabled.
The math is bad, the calculations are incorrect. Below is a program
that displays this problem, but it does not fail when run stand-alone,
this program only fails when run inside of the billing program's context
where it is calculating the statement balances.
The billing program of course does a billion things before it gets to
this point. But at that point the math behavior of PHP is corrupt.
Wrong math results are the only visible sign of the problem, the program
runs to completion and prints the statements etc.
The program reads the numbers from a database as strings and converts
them to floats to do the totals. This is not a case of loss of
precision, as I said the program runs fine on 5.2.5. But sprintf will
convert 19.00 to = 18:0
Note the colon, I'm using the default language settings of USA
English.
Probably related to Bug #47304
Reproduce code:
---
?php
//I ran a series of tests all of them failed,
//it was totally consistent and reproducible.
//Here are the most interesting tests/results.
$arrMsgs = array();
//for the sake of completeness, I also added this,
//it made no difference
$arrMsgs[] = Locale = .setlocale(LC_ALL, english-usa);
$arrMsgs[] = memory_get_peak_usage(true) = .
memory_get_peak_usage(true);
$arrMsgs[] = memory_get_peak_usage(false) = .
memory_get_peak_usage(false);
$arrMsgs[] = memory_get_usage(true) = . memory_get_usage(true);
$arrMsgs[] = memory_get_usage(false) = . memory_get_usage(false);
$arrMsgs[] = (float)19.00 = .(float)19.00;
$arrMsgs[] = (float)'19.00' = .(float)'19.00';
$arrMsgs[] = round('19.00', 2) = .round('19.00', 2);
print_r($arrMsgs);
?
Expected result:
when I run this program on PHP 5.2.5 I get the following result
[DebugInfo] = Array
(
[0] = memory_get_peak_usage(true) = 3932160
[1] = memory_get_peak_usage(false) = 3731872
[2] = memory_get_usage(true) = 3932160
[3] = memory_get_usage(false) = 3589320
[10] = (float)19.00 = 19
[11] = (float)'19.00' = 19
[12] = round('19.00', 2) = 19
)
Actual result:
--
[DebugInfo] = Array
(
[0] = memory_get_peak_usage(true) = 3932160
[1] = memory_get_peak_usage(false) = 3732128
[2] = memory_get_usage(true) = 3932160
[3] = memory_get_usage(false) = 3589216
[10] = (float)19.00 = 18.:
[11] = (float)'19.00' = 18.:
[12] = round('19.00', 2) = 18.:
)
notice the colons following the numbers, I did not add those, it is
part of the failure.
--
Edit this bug report at http://bugs.php.net/?id=47716edit=1
#47304 [Com]: typecast of numeric string to float produces strange result
ID: 47304 Comment by: codeslinger at compsalot dot com Reported By: lennartvdd at mailordersolutions dot nl Status: Feedback Bug Type: Scripting Engine problem Operating System: Server 2003 for SBS SP2 - IIS PHP Version: 5.2.8 Assigned To: pajoye New Comment: Hi pajoye, thank you for the response to bug #47716 you requested that future replies be here. The interesting thing is that when you did a setlocale you got a result back... but when I did it all I get is an empty string, I wondered about this at the time that I entered the bug but did not mention it because I figured the 18:0 vs 19.00 was sufficient. and yes, as it states in that bug, the problem only occurs when a large complex program using lots of memory is running and then within that context you run the repro. if you just do the repro script by itself with nothing else going on then it works just fine. $arrMsgs[] = Locale = .setlocale(LC_ALL, english-usa); [0] = Locale = I will give 5.3 a try and see what happens. Environment: For the testing, I am actually running windows 2000 in a vmware box under Ubuntu on a Pentium M. Previous Comments: [2009-03-20 16:13:06] paj...@php.net For the record, other test cases in #47732 and #47716. It would be interesting to see if 5.3.0 (you can fetch snapshot from http://windows.php.net) suffers from the same problem on the same host. [2009-03-20 16:08:48] paj...@php.net What is the exact version of 2003, which processor do you use? However it works for me with the US locale on XP SP2 (32bit), 2003 (x86), 2008 (x86 and x64), vista (x86 and x64). C:\Users\pierre\Documents\test\php529-1php 47304.php PHP version: 5.2.9-1 float(-39) float(39) float(17) float(-17) float(-39) float(39) float(17) float(-17) [2009-03-20 15:58:36] paj...@php.net What is the last version working correctly? [2009-02-13 01:00:01] 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. [2009-02-05 14:24:34] lennartvdd at mailordersolutions dot nl Yeah weird huh?! I changed back to PHP version: 5.2.0. Float conversion works fine again now! I'll try it on some different machines, but I won't have time to do that until next week, so you'll hear more from me then. 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/47304 -- Edit this bug report at http://bugs.php.net/?id=47304edit=1
#47716 [NEW]: Invalid/Corrupt Math Convert string to float
From: codeslinger at compsalot dot com
Operating system: windows 2000
PHP version: 5.2.9
PHP Bug Type: Scripting Engine problem
Bug description: Invalid/Corrupt Math Convert string to float
Description:
It is with great hesitancy that I enter this bug, because I am not able to
produce a simple test case for it. But the bug is very serious.
I have a program that calculates and sends out customer statements.
Without making any changes to the php program itself which has been
running fine, I upgraded to PHP 5.2.9 and also tested with 5.2.9-1 both
with and without xdebug enabled.
The math is bad, the calculations are incorrect. Below is a program that
displays this problem, but it does not fail when run stand-alone, this
program only fails when run inside of the billing program's context where
it is calculating the statement balances.
The billing program of course does a billion things before it gets to this
point. But at that point the math behavior of PHP is corrupt. Wrong math
results are the only visible sign of the problem, the program runs to
completion and prints the statements etc.
The program reads the numbers from a database as strings and converts them
to floats to do the totals. This is not a case of loss of precision, as I
said the program runs fine on 5.2.5. But sprintf will convert 19.00
to = 18:0
Note the colon, I'm using the default language settings of USA English.
Probably related to Bug #47304
Reproduce code:
---
?php
//I ran a series of tests all of them failed,
//it was totally consistent and reproducible.
//Here are the most interesting tests/results.
$arrMsgs = array();
//for the sake of completeness, I also added this,
//it made no difference
$arrMsgs[] = Locale = .setlocale(LC_ALL, english-usa);
$arrMsgs[] = memory_get_peak_usage(true) = .
memory_get_peak_usage(true);
$arrMsgs[] = memory_get_peak_usage(false) = .
memory_get_peak_usage(false);
$arrMsgs[] = memory_get_usage(true) = . memory_get_usage(true);
$arrMsgs[] = memory_get_usage(false) = . memory_get_usage(false);
$arrMsgs[] = (float)19.00 = .(float)19.00;
$arrMsgs[] = (float)'19.00' = .(float)'19.00';
$arrMsgs[] = round('19.00', 2) = .round('19.00', 2);
print_r($arrMsgs);
?
Expected result:
when I run this program on PHP 5.2.5 I get the following result
[DebugInfo] = Array
(
[0] = memory_get_peak_usage(true) = 3932160
[1] = memory_get_peak_usage(false) = 3731872
[2] = memory_get_usage(true) = 3932160
[3] = memory_get_usage(false) = 3589320
[10] = (float)19.00 = 19
[11] = (float)'19.00' = 19
[12] = round('19.00', 2) = 19
)
Actual result:
--
[DebugInfo] = Array
(
[0] = memory_get_peak_usage(true) = 3932160
[1] = memory_get_peak_usage(false) = 3732128
[2] = memory_get_usage(true) = 3932160
[3] = memory_get_usage(false) = 3589216
[10] = (float)19.00 = 18.:
[11] = (float)'19.00' = 18.:
[12] = round('19.00', 2) = 18.:
)
notice the colons following the numbers, I did not add those, it is part
of the failure.
--
Edit bug report at http://bugs.php.net/?id=47716edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47716r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47716r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47716r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47716r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47716r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47716r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47716r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47716r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47716r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47716r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47716r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47716r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47716r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47716r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47716r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47716r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47716r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47716r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id
#43009 [Com]: headers_sent() is PHP responsibility not Apache! do your job please
ID: 43009 Comment by: codeslinger at compsalot dot com Reported By: hamdi at rawasy dot com Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 4.4.7 New Comment: I just now got around to reading the docs on virtual which your example program is using. This bug is totally bogus. The docs make it very clear what the behavior of virtual is. This behavior is by design. My previous comments about probable causes of headers already sent are valid, they just don't apply to your program example. Previous Comments: [2007-12-19 21:18:07] codeslinger at compsalot dot com apologies for the poor grammar, I should have proof-read more carefully before hitting submit. [2007-12-19 21:08:31] codeslinger at compsalot dot com I suspect your problem is not a bug at all, but is the result of not deciphering an error message that is somewhat mis-leading. What the error message says is headers have already been sent. What you appears to be complaining about is that you have not in fact sent any headers. What you probably don't realize is that any text at all which is seen to be part of the web page, is considered to create a situation of headers already sent. The issue is not actually that the headers have been sent, the issue is that the headers MUST proceed any and all text. The usual cause of this situation is when the php tag is not the actual start of the document. if there is even a single space character in front of the tag it will cause this problem. Also any blank lines after the end of the closing php tag can cause this problem. And be sure to check all of your include files. Blank lines at the end of include files drive me totally nuts until I figured out what was going on. Any character at all, including blank lines, which is outside of the php code brackets is considered to be part of the web page itself. In order to use php to send headers, you CAN'T send any other character at all to the web page. The work-around, for sloppy editing/coding is to turn on output buffering, see the manual. With output buffering enabled, php holds anything being sent, and it is able to insert headers in front of already sent text. But this is really the wrong solution, the right solution is to fix your code. The requirement that headers MUST be sent first is defined by the HTTP protocol itself and can not be changed. [2007-10-17 17:41:35] hamdi at rawasy dot com Description: Referring to my previous report that holds ID 42992 http://bugs.php.net/bug.php?id=42992 Yes, PHP is not responsible about virtual() behavior. But I think that it's holding the full responsibility against headers_sent() behavior and I'm asking to fix headers_sent() not virtual(), as it says that headers was already sent while it wasn't, you could send any headers after that and no problems happens (there is no buffer controllers). So, is it still apache problem? Also the filename line number returned by headers_sent() indicates that headers wasn't sent! and that is stupid behavior Summary You should return true from headers_sent() only when filename line number are set, otherwise return false. I repeat, this bug is PHP problem located at headers_sent() function! Not anything else. I think that your job here is to fix those bugs not throwing blame at others. So, do your job please! Reproduce code: --- ?php virtual(empty.php); // An empty file var_dump(headers_sent($file, $line), $file, $line); ? Expected result: bool(false) string(0) int(0) Actual result: -- bool(true) string(0) int(0) -- Edit this bug report at http://bugs.php.net/?id=43009edit=1
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: codeslinger at compsalot dot com Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: Ping, Can we get php updated please? This problem is now one year old. Everyone who updates to the latest Windows php = 5.2.5 encounters this bug, it results in total breakage of loading the mysql dll. This bug has cost thousands upon thousands of man-hours to be expended/wasted by site admins in trying to locate the cause of the problem and the fix for it. In some cases it has also caused people to abandon the use of php-mysql programs altogether. According to MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 The final resolution is that the problem was with mysql not php and that the problem was fixed awhile ago, and that all that is needed is for php to update to the latest mysql library. Given the fundamental importance of the php mysql interface, as in LAMP, it is inexplicable that it has taken an entire year to resolve what appears to have been a fairly simple fix. Previous Comments: [2008-01-11 21:39:37] jmair at parkcountyre2 dot org IIS 6 on Windows 2003 server fully patched. php 5.2.5 mysql This issue was killing me for a week. I tried every successful attempt from previous posts and no resolve. I was also getting this problem with no mysql. I downloaded and installed fastcgi and followed the manual install for fastcgi and php, not only is the Php not displaying the error, but it's running faster than I've ever seen, maybe almost as fast as a linux box =0 hope this helps somebody. here is the link. http://www.iis.net/articles/view.aspx/IIS7/Hosting-Web-Applications/PHP/Using-FastCGI-to-Host-PHP-Applications-on-IIS-6-0-?Page=2 [2008-01-10 17:49:50] amoo_miki at yahoo dot com This is caused by windows security: to be sure: 1) Check if the drive where PHP is installed is an NTFS partition. 2) If yes, Read Execute for Everyone for the ext folder. php -v at the command-line should not show you the error anymore. [2008-01-07 12:14:01] jaco at jump dot co dot za I was able to reproduce this on a very basic instalation: Apache 2.2.4 PHP 5.2.5 Windows 2003 Server NO Database installed ? $fp = fsockopen(192.168.1.105, 3312); fclose($fp) echo DONE; exit; ? This executes 100%, and gives no errors, but as soon as I stop apache, it gives me the message in the apache error log Error in my_thread_global_end(): 1 threads didn't exit So it seems to me more of a sockets problem than a mysql problem. When I run the same script in CLI, I get no error. [2008-01-04 21:44:17] jaco at jump dot co dot za I am having the same and more problems. I am running: Apache 2.2.6 MySQL 5.0.45 PHP 5.2.5 Windows Server 2003 R2 Standard SP2 2 x Quad Core Xeon 4Gb RAM IIS Installed for SMTP, FTP and WWW on port 443 for a single .NET Webservice access (NO PHP connectors installed for IIS). But I am sure this is not IIS related, becuase it still happens even with IIS stopped Whenever apache tries to recycle threads I get: ** Apache Error Log ** [Fri Jan 04 22:37:38 2008] [notice] Child 324: All worker threads have exited. Error in my_thread_global_end(): 1 threads didn't exit exiting because it reached MaxRequestsPerChild. Signaling the parent to restart a new child process. [Fri Jan 04 22:37:42 2008] [notice] Parent: Received restart signal -- Restarting the server. Note the time difference between the first log and the last log This then causes my Apache to crash and restart. Then I tried to download the latest snapshot of PHP, installed it, but then Apache woould not start at all, just gives me a starting status, but does not het out of it. My problem is also that there is hundreds of php files running and our site is very active, and I have NO idea what is causing this problem. The PHP error log is clean, but the following also shows up AFTER apache crashes. 080104 11:24:26 [Warning] Aborted connection 16865 to db: '' user: '*' host: 'localhost' (Got an error reading communication packets) But I am sure that this is just caused by apache that have crashed and the already open calls to the database that was not terminated by the php script. These messages apears in the event log after the crash: Faulting application httpd.exe, version 2.2.6.0, faulting module libapr-1.dll, version 1.2.11.0, fault address 0x79a0. Faulting application httpd.exe, version 2.2.6.0, faulting module php5ts.dll, version 5.2.5.5, fault address 0xacb9. We are using both mysql and mysqli connectors and I have
#43737 [NEW]: fixing dl() has caused unintended consequences
From: codeslinger at compsalot dot com
Operating system: ALL
PHP version: 5.2.5
PHP Bug Type: Safe Mode/open_basedir
Bug description: fixing dl() has caused unintended consequences
Description:
There is a joke which says
a bug which has a useful side affect is a *feature*
This is a hang-over from the bad old days of beta quality software
releases. But for the first time in my programming career I have
encountered a real life scenario in which that saying is literally true.
The alleged dl() path bug, which has now been ~fixed~, has broken my
(widely deployed) program... or at least it will break if and when we try
to roll out an upgrade to the latest php.
I have been using this ~feature~ since the early days of php 4.
Being able to specify a subdirectory of the Extensions folder is a very
useful feature.
I would ask that you please consider just how many .dll/.so modules that
there actually are. I think it is somewhere around 150 files (many with
obtuse names) and growing, and those are just for the official releases.
Add to this the many 3rd party releases from other sources, and further
consider that quite a few of these modules have negative interactions with
each other. Perhaps you can then appreciate what a huge management problem
this has become.
We are converging upon a state of chaos, not unlike the DLL Hell of
Windows.
I want/need very much to be able to segregate the dlls. I especially need
to be able to keep the 3rd party dlls clearly separate from the official
release dlls.
The extension load code was already able to do this, it was designed such
that you can not specify any arbitrary directory, the only paths that it
would accept were for subdirectories of the defined extension directory. I
believe that this already existing constraint was sufficient to ensure the
security of the modules.
But now with the recent ~bug~ fix all extensions must reside in the same
folder. I know that this was done with the intention that it would make
things more secure. But I respectfully submit for your consideration, that
not being able to segregate the extensions actually makes things less
secure.
Suppose for instance that I have an xyz dll and I only want one php
program to be able to access it. With separate directories I can easily
enforce per user access permissions. With everything in the same directory
it would be much harder to ensure that access rights are consistently
maintained.
Also consider the problem of file name collisions, there is no central
clearing house for the registration of module names. With many independent
developers all creating extensions, file name collisions are inevitable.
And this will lead to hard to fix/detect breakage in the future when a
newly added official release dll clobbers an already existing 3rd party dll
of the same name.
Or consider the problem were you have two versions of a dll which has
incompatible changes. And you have a mixture of php programs some of which
have been updated to use the new version and some which still require the
old version. Yes you could arbitrarily change the name of the dll, but
that introduces long term maintenance headaches if you choose a different
name then the originating source. -- true, it should not happen, the
originator should have assigned a new name, but we all know that it often
does not work that way in the real world. By being able to use separate
subdirectories for the different versions of the dll this becomes a
non-problem.
So I am asking that you please unfix the bug fix and allow subdirectories
to exist inside of the extension folder. No new code is needed for this,
it already used to work. The documentation would need to be updated.
From a security stand-point, I believe that you could achieve your goal by
simply disallowing links, and reviewing that indeed it is not possible to
trick your way to a higher directory level.
I suspect the fundamental conflict here is that php is now performing in 3
different roles and the security requirements for each role are different.
As a cli, php has become a viable replacment for perl. I now write php
programs as the system glue, for all the things that were traditionally
done by perl. In cli mode while performing system maintenance tasks, these
fully trusted php programs must be unencumbered or else they will be unable
to perform the needed functions.
On the other hand, in it's role as mod_php it needs very tight
constraints, especially when running untrusted code. and in order to
function, cgi_php is a little bit less restricted than mod_php.
But in all of those security modes, it would be useful to be able to
segregate the extensions into multiple directories.
Thank you
Reproduce code:
---
//create a directory under the extensions directory
//and put foo.dll in it
dl('subfolder/foo.dll');
//or even
dl('/subfolder/foo.dll');
Expected result:
foo.dll
#43009 [Com]: headers_sent() is PHP responsibility not Apache! do your job please
ID: 43009 Comment by: codeslinger at compsalot dot com Reported By: hamdi at rawasy dot com Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 4.4.7 New Comment: I suspect your problem is not a bug at all, but is the result of not deciphering an error message that is somewhat mis-leading. What the error message says is headers have already been sent. What you appears to be complaining about is that you have not in fact sent any headers. What you probably don't realize is that any text at all which is seen to be part of the web page, is considered to create a situation of headers already sent. The issue is not actually that the headers have been sent, the issue is that the headers MUST proceed any and all text. The usual cause of this situation is when the php tag is not the actual start of the document. if there is even a single space character in front of the tag it will cause this problem. Also any blank lines after the end of the closing php tag can cause this problem. And be sure to check all of your include files. Blank lines at the end of include files drive me totally nuts until I figured out what was going on. Any character at all, including blank lines, which is outside of the php code brackets is considered to be part of the web page itself. In order to use php to send headers, you CAN'T send any other character at all to the web page. The work-around, for sloppy editing/coding is to turn on output buffering, see the manual. With output buffering enabled, php holds anything being sent, and it is able to insert headers in front of already sent text. But this is really the wrong solution, the right solution is to fix your code. The requirement that headers MUST be sent first is defined by the HTTP protocol itself and can not be changed. Previous Comments: [2007-10-17 17:41:35] hamdi at rawasy dot com Description: Referring to my previous report that holds ID 42992 http://bugs.php.net/bug.php?id=42992 Yes, PHP is not responsible about virtual() behavior. But I think that it's holding the full responsibility against headers_sent() behavior and I'm asking to fix headers_sent() not virtual(), as it says that headers was already sent while it wasn't, you could send any headers after that and no problems happens (there is no buffer controllers). So, is it still apache problem? Also the filename line number returned by headers_sent() indicates that headers wasn't sent! and that is stupid behavior Summary You should return true from headers_sent() only when filename line number are set, otherwise return false. I repeat, this bug is PHP problem located at headers_sent() function! Not anything else. I think that your job here is to fix those bugs not throwing blame at others. So, do your job please! Reproduce code: --- ?php virtual(empty.php); // An empty file var_dump(headers_sent($file, $line), $file, $line); ? Expected result: bool(false) string(0) int(0) Actual result: -- bool(true) string(0) int(0) -- Edit this bug report at http://bugs.php.net/?id=43009edit=1
#43009 [Com]: headers_sent() is PHP responsibility not Apache! do your job please
ID: 43009 Comment by: codeslinger at compsalot dot com Reported By: hamdi at rawasy dot com Status: Open Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 4.4.7 New Comment: apologies for the poor grammar, I should have proof-read more carefully before hitting submit. Previous Comments: [2007-12-19 21:08:31] codeslinger at compsalot dot com I suspect your problem is not a bug at all, but is the result of not deciphering an error message that is somewhat mis-leading. What the error message says is headers have already been sent. What you appears to be complaining about is that you have not in fact sent any headers. What you probably don't realize is that any text at all which is seen to be part of the web page, is considered to create a situation of headers already sent. The issue is not actually that the headers have been sent, the issue is that the headers MUST proceed any and all text. The usual cause of this situation is when the php tag is not the actual start of the document. if there is even a single space character in front of the tag it will cause this problem. Also any blank lines after the end of the closing php tag can cause this problem. And be sure to check all of your include files. Blank lines at the end of include files drive me totally nuts until I figured out what was going on. Any character at all, including blank lines, which is outside of the php code brackets is considered to be part of the web page itself. In order to use php to send headers, you CAN'T send any other character at all to the web page. The work-around, for sloppy editing/coding is to turn on output buffering, see the manual. With output buffering enabled, php holds anything being sent, and it is able to insert headers in front of already sent text. But this is really the wrong solution, the right solution is to fix your code. The requirement that headers MUST be sent first is defined by the HTTP protocol itself and can not be changed. [2007-10-17 17:41:35] hamdi at rawasy dot com Description: Referring to my previous report that holds ID 42992 http://bugs.php.net/bug.php?id=42992 Yes, PHP is not responsible about virtual() behavior. But I think that it's holding the full responsibility against headers_sent() behavior and I'm asking to fix headers_sent() not virtual(), as it says that headers was already sent while it wasn't, you could send any headers after that and no problems happens (there is no buffer controllers). So, is it still apache problem? Also the filename line number returned by headers_sent() indicates that headers wasn't sent! and that is stupid behavior Summary You should return true from headers_sent() only when filename line number are set, otherwise return false. I repeat, this bug is PHP problem located at headers_sent() function! Not anything else. I think that your job here is to fix those bugs not throwing blame at others. So, do your job please! Reproduce code: --- ?php virtual(empty.php); // An empty file var_dump(headers_sent($file, $line), $file, $line); ? Expected result: bool(false) string(0) int(0) Actual result: -- bool(true) string(0) int(0) -- Edit this bug report at http://bugs.php.net/?id=43009edit=1
#42339 [Fbk-Opn]: using --without-apxs2 results in an error/abort; configuring the release build
ID: 42339 User updated by: codeslinger at compsalot dot com -Summary: Can't Build a CLI *only* must have APXS enabled Reported By: codeslinger at compsalot dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: SimplyMEPIS Linux 6.5 PHP Version: 5.2.3 New Comment: Hi Jani, Thank you for looking at this, I appreciate your efforts. Using the snap from 2007-08-26 at 04:30 I can not reproduce the problem. Therefore the problem has been fixed in cvs and that's why you aren't seeing it. However, in the release version of php 5.2.3 using the following command continues to result in the error message and abort as described. ./configure --without-apxs2 What appears to be happening is that without is being mistaken for a with request. And since the default path does not match the actual path it aborts with a not found error. The reason I was specifying --without-apxs2 is because I wanted to make certain that apxs would not be built and clobber my previous apxs which has different/incompatible configure options. My assumption was that because the cgi gets built even when it is not requested, that the apxs was also probably being built. Now that I understand better how to interpret the many thousands of lines of output... I see that apxs is not being built unless specifically requested. I do not recall seeing this fact (that cgi gets built and apxs does not, by default) anywhere in the documentation. Previous Comments: [2007-08-23 09:19:12] [EMAIL PROTECTED] # ./configure --disable-cgi or # ./configure --without-apxs2 Both work just fine here. You're simply doing something wrong or I'm high on crack. :) I even removed Apache from my test machine to be sure. Any other SAPIs aren't enabled by default except for CLI and CGI. With plain ./configure without any options you get both. Please it with this latest snapshot instead of 5.2.3: http://snaps.php.net/php5.2-latest.tar.gz [2007-08-22 19:13:53] codeslinger at compsalot dot com The sources used are fine, I downloaded them direct from php.net and verified the md5. The documentation on the options is incomplete. I tried --without-apxs because even though it is not documented, it is symmetrical to the option --with-apxs which is documented, but that did not work. Also, not saying anything about apxs at all did not work either. Everything I tried, the ./configure failed. After entering this bug and thinking about it some more, it occurred to me to try --disable-apxs and did discover that it was the only thing which produced the desired behavior of a CLI only build. And that's when I changed the category to a documentation bug. Anything else results in the error: Sorry, I was not able to successfully run APXS. I get that error even though I have not specified --with-apxs. php by default is trying to build the apxs version even when it is not requested. I note in the change log that there have been some recent changes to the make. perhaps this problem is newly introduced. Also my actual goal was to build both CGI and CLI at the same time, but for the purpose of this bug I decided to simplify and isolate as much as possible. [2007-08-20 07:48:19] [EMAIL PROTECTED] This is not true. Simply doing './configure --disable-cgi' gives you CLI. There isn't such option as '--disable-apxs'.. You propably used unclean sources. [2007-08-18 17:46:21] codeslinger at compsalot dot com this is actually a documentation problem. the correct command should be './configure'--enable-cli --disable-cgi --disable-apxs [2007-08-18 17:36:23] codeslinger at compsalot dot com Description: There are many options for PHP, such as ncurses, which are not compatible with phpN-mod.so But when trying to build a CLI only config, it fails with an error message that APXS is not enabled. Reproduce code: --- I tried many variants, here is the simplest: './configure'--enable-cli--disable-cgi --without-apxs2 --without-apxs Expected result: Expected: No errors Note: the following command *does* work './configure'--enable-cli--disable-cgi '--with-apxs2=/usr/bin/apxs2' Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your
#42339 [Bgs-Opn]: Can't Build a CLI *only* must have APXS enabled
ID: 42339 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: SimplyMEPIS Linux 6.5 PHP Version: 5.2.3 New Comment: The sources used are fine, I downloaded them direct from php.net and verified the md5. The documentation on the options is incomplete. I tried --without-apxs because even though it is not documented, it is symmetrical to the option --with-apxs which is documented, but that did not work. Also, not saying anything about apxs at all did not work either. Everything I tried, the ./configure failed. After entering this bug and thinking about it some more, it occurred to me to try --disable-apxs and did discover that it was the only thing which produced the desired behavior of a CLI only build. And that's when I changed the category to a documentation bug. Anything else results in the error: Sorry, I was not able to successfully run APXS. I get that error even though I have not specified --with-apxs. php by default is trying to build the apxs version even when it is not requested. I note in the change log that there have been some recent changes to the make. perhaps this problem is newly introduced. Also my actual goal was to build both CGI and CLI at the same time, but for the purpose of this bug I decided to simplify and isolate as much as possible. Previous Comments: [2007-08-20 07:48:19] [EMAIL PROTECTED] This is not true. Simply doing './configure --disable-cgi' gives you CLI. There isn't such option as '--disable-apxs'.. You propably used unclean sources. [2007-08-18 17:46:21] codeslinger at compsalot dot com this is actually a documentation problem. the correct command should be './configure'--enable-cli --disable-cgi --disable-apxs [2007-08-18 17:36:23] codeslinger at compsalot dot com Description: There are many options for PHP, such as ncurses, which are not compatible with phpN-mod.so But when trying to build a CLI only config, it fails with an error message that APXS is not enabled. Reproduce code: --- I tried many variants, here is the simplest: './configure'--enable-cli--disable-cgi --without-apxs2 --without-apxs Expected result: Expected: No errors Note: the following command *does* work './configure'--enable-cli--disable-cgi '--with-apxs2=/usr/bin/apxs2' Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /usr/local/src/php-5.2.3/no follows ./configure: line 4396: /usr/local/src/php-5.2.3/no: No such file or directory configure: error: Aborting -- Edit this bug report at http://bugs.php.net/?id=42339edit=1
#42339 [NEW]: Can't Build a CLI *only* must have APXS enabled
From: codeslinger at compsalot dot com Operating system: SimplyMEPIS Linux 6.5 PHP version: 5.2.3 PHP Bug Type: Compile Failure Bug description: Can't Build a CLI *only* must have APXS enabled Description: There are many options for PHP, such as ncurses, which are not compatible with phpN-mod.so But when trying to build a CLI only config, it fails with an error message that APXS is not enabled. Reproduce code: --- I tried many variants, here is the simplest: './configure'--enable-cli--disable-cgi --without-apxs2 --without-apxs Expected result: Expected: No errors Note: the following command *does* work './configure'--enable-cli--disable-cgi '--with-apxs2=/usr/bin/apxs2' Actual result: -- Configuring SAPI modules checking for AOLserver support... no checking for Apache 1.x module support via DSO through APXS... Sorry, I was not able to successfully run APXS. Possible reasons: 1. Perl is not installed; 2. Apache was not compiled with DSO support (--enable-module=so); 3. 'apxs' is not in your path. Try to use --with-apxs=/path/to/apxs The output of /usr/local/src/php-5.2.3/no follows ./configure: line 4396: /usr/local/src/php-5.2.3/no: No such file or directory configure: error: Aborting -- Edit bug report at http://bugs.php.net/?id=42339edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42339r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42339r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42339r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42339r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42339r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42339r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42339r=needscript Try newer version:http://bugs.php.net/fix.php?id=42339r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42339r=support Expected behavior:http://bugs.php.net/fix.php?id=42339r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42339r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42339r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42339r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42339r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42339r=dst IIS Stability:http://bugs.php.net/fix.php?id=42339r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42339r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42339r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42339r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42339r=mysqlcfg
#41023 [NEW]: Enhance PHP With a Fluent Interface
From: codeslinger at compsalot dot com
Operating system: any
PHP version: 5.2.1
PHP Bug Type: Feature/Change Request
Bug description: Enhance PHP With a Fluent Interface
Description:
Given all of the buzz about Fluent Interface programming, see for
instance: http://devzone.zend.com/node/view/id/1362
I decided that it would be appropriate for me to request the one feature
more than any other that I miss not having in the fantastically fabulous
PHP.
The With operator provides an implied scope for any object Method which
does not otherwise specify an explicit object.
The goal is to increase the readability of complex programs which contain
repetitive object references (the usual case). It also reduces typing ==
effort, and potentially enables the compiler to optimize performance/access
to the object. As an additional bonus, maintenance and clarity is
increased because there is a central point for the refered to object in a
block of code, thus requiring one change instead of many.
I refer you to discussions elsewhere as to the desirability of this
syntatic sugar.
1) http://devzone.zend.com/node/view/id/1362
2) http://www.mikenaberezny.com/archives/35
3) http://en.wikipedia.org/wiki/Fluent_interface
4) http://martinfowler.com/bliki/FluentInterface.html
5)
http://schlitt.info/applications/blog/index.php?/archives/400-A-sensible-place-for-a-fluent-interface.html
Reproduce code:
---
---
Thus:
$oMyFoo = new ClassFoo;
$oMyFoo-DoSomething();
$oMyFoo-DoSomethingElse();
$oMyFoo-DoOther();
$oMyFoo-DoEtc();
$Assigned = $oMyFoo-DoSomethingElse() + $oMyFoo-SomeOther() +
$oMyFoo-Another();
Expected result:
-
Under the Fluent Interface paradigm in which every Method returns a
reference to *the* object, it becomes:
$oMyFoo = new ClassFoo;
$oMyFoo-DoSomething()
-DoSomethingElse()
-DoOther()
-DoEtc()
;
Note that the above is really just:
$oMyFoo-DoSomething()-DoSomethingElse()-DoOther()-DoEtc();
However, the object class must be specially written to support this and
you can not return other values, thus the $Assigned = is not possible.
But by implementing a With construct, any object can be used without
modification, and you do not give up the ability to return values.
-
Desired Approach:
$oMyFoo = new ClassFoo;
With($oMyFoo)
{
-DoSomething();
-DoSomethingElse();
-DoOther();
-DoEtc();
$Assigned = -DoSomethingElse() + -SomeOther() + -Another();
}
For any unqualified Method, the referent object is defined by the With
clause. Naturally, With can be nested.
As you can see, the readability of the code is greatly enhanced and full
functionality is retained.
--
Edit bug report at http://bugs.php.net/?id=41023edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41023r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41023r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41023r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41023r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41023r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41023r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41023r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41023r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41023r=support
Expected behavior:http://bugs.php.net/fix.php?id=41023r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41023r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41023r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41023r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41023r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41023r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41023r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41023r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41023r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41023r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41023r=mysqlcfg
#39720 [NEW]: Compile Fails with php_config.h: No such file or directory
From: codeslinger at compsalot dot com Operating system: Fedora Core 2 PHP version: 5.2.0 PHP Bug Type: Compile Failure Bug description: Compile Fails with php_config.h: No such file or directory Description: I am attempting to install PHP 5.2.0 cli (from tarball) onto my server. The server is a Fedora Core 2. I have previously installed php-4.3.10 onto this server (from tarball) without difficulty. First Problem I ran into was the dependency on libxml. After an initial attempt to disable PHP5s use of libxml, I gave in and (attempted to) install libxml from tarball. Next Problem was that libxml 2.2.6.27, despite claims of being stand-alone, is in fact dependent upon python. Fedora Core 2 has python version 2.2 preinstalled from rpms. libxml 2.2.6.27 was not happy with this version of python. So I ended up installing python 2.5 using a --prefix and leaving the original intact. Python 2.5 installed without difficulty After some additional tweaking with ld.so.conf; libxml installed without further difficulty. also using a --prefix However, PHP 5.2.0 cli still refused to install. I then became very aggressive about eliminating/disabling functionality to get it to a lowest complexity build. Reproduce code: --- ./configure --no-create --enable-cli --enable-pcntl --enable-posix --enable-shmop --enable-sigchild --enable-sockets --enable-memory-limit --enable-track-vars --prefix=/usr/local/php5 --with-config-file-path=/etc/php5 --with-config-file-scan-dir=/etc/php5/php5.d --datadir=/var/tmp/php5/data --localstatedir=/var/tmp/php5 --sharedstatedir=/var/tmp/php5/com --sysconfdir=/etc --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=./config.cache --disable-debug --disable-magic-quotes --without-oci8 --with-mime-magic=/usr/share/magic.mime --enable-bcmath --disable-xml --disable-libxml --disable-dom --disable-simplexml --disable-wddx --disable-xmlreader --disable-xmlwriter --without-pear --disable-openssl --disable-pcre make clean make Note: Despite the fact that I have specified to disable PCRE, PHP5 still insists upon compiling it. Expected result: for a PHP5 cli to be built that can co-exist with a PHP4 cli Actual result: -- In file included from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_ucp_searchfuncs.c:44: /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_internal.h:71:25: php_config.h: No such file or directory In file included from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre.h:42, from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_internal.h:149, from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_ucp_searchfuncs.c:44: /usr/local/src/files/php/php-5.2.0/main/php_compat.h:27:24: php_config.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_ucp_searchfuncs.lo] Error 1 Note: The version of perl which is on this server is v5.8.4. This was also preinstalled via rpm. It is not clear to me if there is a seperate PCRE package that I need to update. It appears to me that PHP is supplying all of the code for the PCRE package. -- Edit bug report at http://bugs.php.net/?id=39720edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39720r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39720r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39720r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39720r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39720r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39720r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39720r=needscript Try newer version:http://bugs.php.net/fix.php?id=39720r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39720r=support Expected behavior:http://bugs.php.net/fix.php?id=39720r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39720r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39720r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39720r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39720r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39720r=dst IIS Stability:http://bugs.php.net/fix.php?id=39720r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39720r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39720r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39720r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39720r=mysqlcfg
#39720 [Opn]: Compile Fails with php_config.h: No such file or directory
ID: 39720 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com Status: Open -Bug Type: Compile Failure +Bug Type: Feature/Change Request Operating System: Fedora Core 2 PHP Version: 5.2.0 New Comment: oops for the sake of paronia, to protect the existing PHP4 installation. I have been testing with the --no-create flag While reviewing the bug, I realized the flag was there. When I removed it the Build proceded. Therefore: This Bug is Now a Feature Request for a Meaningful Warning Message when the --no-create flag is in use. I have spent far too much time on trying to isolate the cause of this problem. A simple Warning Message would have been a huge help and saved much aggravation. Thank you. Previous Comments: [2006-12-03 06:19:48] codeslinger at compsalot dot com Description: I am attempting to install PHP 5.2.0 cli (from tarball) onto my server. The server is a Fedora Core 2. I have previously installed php-4.3.10 onto this server (from tarball) without difficulty. First Problem I ran into was the dependency on libxml. After an initial attempt to disable PHP5s use of libxml, I gave in and (attempted to) install libxml from tarball. Next Problem was that libxml 2.2.6.27, despite claims of being stand-alone, is in fact dependent upon python. Fedora Core 2 has python version 2.2 preinstalled from rpms. libxml 2.2.6.27 was not happy with this version of python. So I ended up installing python 2.5 using a --prefix and leaving the original intact. Python 2.5 installed without difficulty After some additional tweaking with ld.so.conf; libxml installed without further difficulty. also using a --prefix However, PHP 5.2.0 cli still refused to install. I then became very aggressive about eliminating/disabling functionality to get it to a lowest complexity build. Reproduce code: --- ./configure --no-create --enable-cli --enable-pcntl --enable-posix --enable-shmop --enable-sigchild --enable-sockets --enable-memory-limit --enable-track-vars --prefix=/usr/local/php5 --with-config-file-path=/etc/php5 --with-config-file-scan-dir=/etc/php5/php5.d --datadir=/var/tmp/php5/data --localstatedir=/var/tmp/php5 --sharedstatedir=/var/tmp/php5/com --sysconfdir=/etc --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=./config.cache --disable-debug --disable-magic-quotes --without-oci8 --with-mime-magic=/usr/share/magic.mime --enable-bcmath --disable-xml --disable-libxml --disable-dom --disable-simplexml --disable-wddx --disable-xmlreader --disable-xmlwriter --without-pear --disable-openssl --disable-pcre make clean make Note: Despite the fact that I have specified to disable PCRE, PHP5 still insists upon compiling it. Expected result: for a PHP5 cli to be built that can co-exist with a PHP4 cli Actual result: -- In file included from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_ucp_searchfuncs.c:44: /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_internal.h:71:25: php_config.h: No such file or directory In file included from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre.h:42, from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_internal.h:149, from /usr/local/src/files/php/php-5.2.0/ext/pcre/pcrelib/pcre_ucp_searchfuncs.c:44: /usr/local/src/files/php/php-5.2.0/main/php_compat.h:27:24: php_config.h: No such file or directory make: *** [ext/pcre/pcrelib/pcre_ucp_searchfuncs.lo] Error 1 Note: The version of perl which is on this server is v5.8.4. This was also preinstalled via rpm. It is not clear to me if there is a seperate PCRE package that I need to update. It appears to me that PHP is supplying all of the code for the PCRE package. -- Edit this bug report at http://bugs.php.net/?id=39720edit=1
#39667 [NEW]: class extends should parse a T_VARIABLE
From: codeslinger at compsalot dot com
Operating system: Any
PHP version: 5.2.0
PHP Bug Type: Feature/Change Request
Bug description: class extends should parse a T_VARIABLE
Description:
Feature Request:
The construct: class foo2 extends foo1{}
will only accept a T_STRING for foo1
But what is highly desired is to also accept a T_VARIABLE.
class $strFoo2 extends $strFoo1{}
Should be a valid construct. This would enable some very powerful
techniques, such as object encapsulation and psudo-nesting.
Reproduce code:
---
//Goal: To encapsulate a multiply subclassed object
class foo1{
function foo1{echo foo1\n;}
}
$MyClass = foo1;
class foo2 extends $MyClass{
function CoolExtention1{echo Cool Extension #1\n;}
}
$MyClass = foo2;
class foo3 extends $MyClass{
function TotallyCoolExt{echo Totally Cool Ext #2\n;}
}
$MyClass = foo3;
//
//
// The program now sees an encapsulated class
// without having to know anything in advance.
// and without having to be modified when changes
// are made to the object.
$MyObj = new $MyClass;
Expected result:
/***
It's a question of being able to isolate the dependancies
I don't want to hard-code the class names because I have
multiple alternative extendors for the base class. It's
basically a bunch of building blocks that I assemble as
needed to create a custom class, giving me a common
interface but with different functional implementations.
I want the consuming program to see a single encapsulated
object class. Aggrate does not do inheritance.
PHP5 has Great!!! tools for working with objects and
functions. But Encapsulation is one area it lacks and
which could easily? be added by enabling the class
definition to parse T_VARIABLEs and then using the trick
above. This gives you the functional equivlent of nested
classes as long as you manage your references carefully.
I did manage to get this working using eval, but it's an
ugly hack when dealing with a class of any complexity.
\$everywhere. I also have some concerns about what the
eval approach may be doing to runtime performance versus
what could be done at cachable compile time.
/
Taking it to the next level...a trick nobody else can do?
class $strfoo2 extends $MyClass{
function {$strfoo2}{echo Awesome $strfoo2 class!\n;}
}
***/
Actual result:
--
Parse error: unexpected T_VARIABLE, expecting T_STRING
--
Edit bug report at http://bugs.php.net/?id=39667edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39667r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39667r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39667r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39667r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39667r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39667r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39667r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39667r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39667r=support
Expected behavior:http://bugs.php.net/fix.php?id=39667r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39667r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39667r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39667r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39667r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39667r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39667r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39667r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39667r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39667r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39667r=mysqlcfg
#31787 [Bgs]: Parse Error -- Comment of // slash slash fails to ignore script terminator
ID: 31787 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.10 New Comment: for anyone else reading this bug... the answer is because of code blocks e.g. embeded code. Consider: ?php echo foo; //a comment ? ihtml here/i?php echo more foo; ? if the parser just looked for the end of line it would skip valid stuff. Previous Comments: [2005-02-04 07:14:11] codeslinger at compsalot dot com okay, thanks. But I still think it's strange for the parser to be wasting time, parsing code inside of a comment, when all it needs to be doing is looking for the end of line. [2005-02-03 18:53:10] [EMAIL PROTECTED] This is not discussion forum. Discuss on the mailing lists. Documentation can be found at: http://www.php.net/manual/en/language.basic-syntax.comments.php Read the last paragraph on that page. [2005-02-03 18:49:00] codeslinger at compsalot dot com Thank you for your response. But I wanted some further discussion on this. I spent a *lot* of time banging my head against the wall trying to track down a nonsensical error message. I took the totally legitimate statment of fwrite($fp, ?php echo 'Hello World'; ? ); And commented it out with //. And instead of ignoring the comment, php decided to interpet it as a script close tag. This bogus parsing behavior lead to major frustration and confusion; and wasted time. Now my understanding of // is that everything up to the end of the line is supposed to be ignored. Not only is the ? within a comment, but it is also contained inside of quotes... Why is the parser spinning it's wheels parsing the contents of a comment, when all it needs to be doing is a skip to end of line? -- Per your suggestion, I did a search for html containment I did not find anything. I did find and read chapter 71, but saw nothing applicable. I have actually read quite a bit of the manual, but as you know it is huge and navigation can be tricky, if you could give me a more specific link I would appreciate it. -- Please understand that I LOVE PHP and I am very very greatful for all the hard work that people have put in. I am not intending to be overly critical. [2005-02-01 09:24:03] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read the docs on html containment - this is expected. [2005-02-01 00:46:55] codeslinger at compsalot dot com I doubt it makes a difference, but this is the CLI version of php. 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/31787 -- Edit this bug report at http://bugs.php.net/?id=31787edit=1
#31787 [Bgs-Opn]: Parse Error -- Comment of // slash slash fails to ignore script terminator
ID: 31787 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.10 New Comment: Thank you for your response. But I wanted some further discussion on this. I spent a *lot* of time banging my head against the wall trying to track down a nonsensical error message. I took the totally legitimate statment of fwrite($fp, ?php echo 'Hello World'; ? ); And commented it out with //. And instead of ignoring the comment, php decided to interpet it as a script close tag. This bogus parsing behavior lead to major frustration and confusion; and wasted time. Now my understanding of // is that everything up to the end of the line is supposed to be ignored. Not only is the ? within a comment, but it is also contained inside of quotes... Why is the parser spinning it's wheels parsing the contents of a comment, when all it needs to be doing is a skip to end of line? -- Per your suggestion, I did a search for html containment I did not find anything. I did find and read chapter 71, but saw nothing applicable. I have actually read quite a bit of the manual, but as you know it is huge and navigation can be tricky, if you could give me a more specific link I would appreciate it. -- Please understand that I LOVE PHP and I am very very greatful for all the hard work that people have put in. I am not intending to be overly critical. Previous Comments: [2005-02-01 09:24:03] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read the docs on html containment - this is expected. [2005-02-01 00:46:55] codeslinger at compsalot dot com I doubt it makes a difference, but this is the CLI version of php. [2005-02-01 00:36:23] codeslinger at compsalot dot com Description: Here is a bizarre script parsing problem The // comment operator is supposed to ignore everything on that line. But if you happen to do something like // fwrite($pipes[0], ?php echo 'Hello World'; ? ); Then you start getting all kinds of strange parse errors. I isolated the problem. What is happening is that // ? or even // ? is being interpeted as the script terminator. Happily /* ? */ does work Reproduce code: --- ?php // ? echo we get an error because it sees the ? in the comment; ? # The above will fail, but this works ?php /* ? */ echo the ? is properly ignored; ? Expected result: anything and everything following a // to be ignored Actual result: -- Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /foo/phpchild/parent1.php on line 29 Parse error: parse error, unexpected ')', expecting ',' or ';' in /foo/phpchild/parent1.php on line 29 The actual error depends on the specific code following the termination point. This thing really had me baffeled for awhile... I commented out several lines of code and started getting parse errors about missing parens and semicolons, etc. Depending upon what I commented out, the error would change, which made it very hard to track down. Naturally I assumed I had made a mistake, mismatched quotes etc. Took me quite a bit of head banging to finally figure out what was going on. = Are you sure that you searched before you submitted your bug report? By the way You don't allow searching for specific characters such as // and ? this makes it very hard to check for duplicates of this bug I note that your auto-dup detector did search for // in fact it did a very impressive job of finding similar bugs. But no dups. -- Edit this bug report at http://bugs.php.net/?id=31787edit=1
#31787 [Bgs-Csd]: Parse Error -- Comment of // slash slash fails to ignore script terminator
ID: 31787 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com -Status: Bogus +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.10 New Comment: okay, thanks. But I still think it's strange for the parser to be wasting time, parsing code inside of a comment, when all it needs to be doing is looking for the end of line. Previous Comments: [2005-02-03 18:53:10] [EMAIL PROTECTED] This is not discussion forum. Discuss on the mailing lists. Documentation can be found at: http://www.php.net/manual/en/language.basic-syntax.comments.php Read the last paragraph on that page. [2005-02-03 18:49:00] codeslinger at compsalot dot com Thank you for your response. But I wanted some further discussion on this. I spent a *lot* of time banging my head against the wall trying to track down a nonsensical error message. I took the totally legitimate statment of fwrite($fp, ?php echo 'Hello World'; ? ); And commented it out with //. And instead of ignoring the comment, php decided to interpet it as a script close tag. This bogus parsing behavior lead to major frustration and confusion; and wasted time. Now my understanding of // is that everything up to the end of the line is supposed to be ignored. Not only is the ? within a comment, but it is also contained inside of quotes... Why is the parser spinning it's wheels parsing the contents of a comment, when all it needs to be doing is a skip to end of line? -- Per your suggestion, I did a search for html containment I did not find anything. I did find and read chapter 71, but saw nothing applicable. I have actually read quite a bit of the manual, but as you know it is huge and navigation can be tricky, if you could give me a more specific link I would appreciate it. -- Please understand that I LOVE PHP and I am very very greatful for all the hard work that people have put in. I am not intending to be overly critical. [2005-02-01 09:24:03] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Please read the docs on html containment - this is expected. [2005-02-01 00:46:55] codeslinger at compsalot dot com I doubt it makes a difference, but this is the CLI version of php. [2005-02-01 00:36:23] codeslinger at compsalot dot com Description: Here is a bizarre script parsing problem The // comment operator is supposed to ignore everything on that line. But if you happen to do something like // fwrite($pipes[0], ?php echo 'Hello World'; ? ); Then you start getting all kinds of strange parse errors. I isolated the problem. What is happening is that // ? or even // ? is being interpeted as the script terminator. Happily /* ? */ does work Reproduce code: --- ?php // ? echo we get an error because it sees the ? in the comment; ? # The above will fail, but this works ?php /* ? */ echo the ? is properly ignored; ? Expected result: anything and everything following a // to be ignored Actual result: -- Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /foo/phpchild/parent1.php on line 29 Parse error: parse error, unexpected ')', expecting ',' or ';' in /foo/phpchild/parent1.php on line 29 The actual error depends on the specific code following the termination point. This thing really had me baffeled for awhile... I commented out several lines of code and started getting parse errors about missing parens and semicolons, etc. Depending upon what I commented out, the error would change, which made it very hard to track down. Naturally I assumed I had made a mistake, mismatched quotes etc. Took me quite a bit of head banging to finally figure out what was going on. = Are you sure that you searched before you submitted your bug report? By the way You don't allow searching for specific characters such as // and ? this makes it very hard to check for duplicates of this bug I note that your auto-dup detector did search for // in fact it did a very impressive job of finding similar bugs. But no dups. -- Edit this bug report at http://bugs.php.net/?id=31787edit=1
#31787 [NEW]: Parse Error -- Comment of // slash slash fails to ignore script terminator
From: codeslinger at compsalot dot com Operating system: Linux PHP version: 4.3.10 PHP Bug Type: Scripting Engine problem Bug description: Parse Error -- Comment of // slash slash fails to ignore script terminator Description: Here is a bizarre script parsing problem The // comment operator is supposed to ignore everything on that line. But if you happen to do something like // fwrite($pipes[0], ?php echo 'Hello World'; ? ); Then you start getting all kinds of strange parse errors. I isolated the problem. What is happening is that // ? or even // ? is being interpeted as the script terminator. Happily /* ? */ does work Reproduce code: --- ?php // ? echo we get an error because it sees the ? in the comment; ? # The above will fail, but this works ?php /* ? */ echo the ? is properly ignored; ? Expected result: anything and everything following a // to be ignored Actual result: -- Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /foo/phpchild/parent1.php on line 29 Parse error: parse error, unexpected ')', expecting ',' or ';' in /foo/phpchild/parent1.php on line 29 The actual error depends on the specific code following the termination point. This thing really had me baffeled for awhile... I commented out several lines of code and started getting parse errors about missing parens and semicolons, etc. Depending upon what I commented out, the error would change, which made it very hard to track down. Naturally I assumed I had made a mistake, mismatched quotes etc. Took me quite a bit of head banging to finally figure out what was going on. = Are you sure that you searched before you submitted your bug report? By the way You don't allow searching for specific characters such as // and ? this makes it very hard to check for duplicates of this bug I note that your auto-dup detector did search for // in fact it did a very impressive job of finding similar bugs. But no dups. -- Edit bug report at http://bugs.php.net/?id=31787edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31787r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31787r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31787r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31787r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31787r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31787r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31787r=needscript Try newer version: http://bugs.php.net/fix.php?id=31787r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31787r=support Expected behavior: http://bugs.php.net/fix.php?id=31787r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31787r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31787r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31787r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31787r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31787r=dst IIS Stability: http://bugs.php.net/fix.php?id=31787r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31787r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31787r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31787r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31787r=mysqlcfg
#31787 [Opn]: Parse Error -- Comment of // slash slash fails to ignore script terminator
ID: 31787 User updated by: codeslinger at compsalot dot com Reported By: codeslinger at compsalot dot com Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.10 New Comment: I doubt it makes a difference, but this is the CLI version of php. Previous Comments: [2005-02-01 00:36:23] codeslinger at compsalot dot com Description: Here is a bizarre script parsing problem The // comment operator is supposed to ignore everything on that line. But if you happen to do something like // fwrite($pipes[0], ?php echo 'Hello World'; ? ); Then you start getting all kinds of strange parse errors. I isolated the problem. What is happening is that // ? or even // ? is being interpeted as the script terminator. Happily /* ? */ does work Reproduce code: --- ?php // ? echo we get an error because it sees the ? in the comment; ? # The above will fail, but this works ?php /* ? */ echo the ? is properly ignored; ? Expected result: anything and everything following a // to be ignored Actual result: -- Warning: Unexpected character in input: '\' (ASCII=92) state=1 in /foo/phpchild/parent1.php on line 29 Parse error: parse error, unexpected ')', expecting ',' or ';' in /foo/phpchild/parent1.php on line 29 The actual error depends on the specific code following the termination point. This thing really had me baffeled for awhile... I commented out several lines of code and started getting parse errors about missing parens and semicolons, etc. Depending upon what I commented out, the error would change, which made it very hard to track down. Naturally I assumed I had made a mistake, mismatched quotes etc. Took me quite a bit of head banging to finally figure out what was going on. = Are you sure that you searched before you submitted your bug report? By the way You don't allow searching for specific characters such as // and ? this makes it very hard to check for duplicates of this bug I note that your auto-dup detector did search for // in fact it did a very impressive job of finding similar bugs. But no dups. -- Edit this bug report at http://bugs.php.net/?id=31787edit=1
#26913 [NEW]: browscap.ini is out of date returns wrong info for IE6.0 and above
From: codeslinger at compsalot dot com
Operating system: All
PHP version: 4.3.4
PHP Bug Type: PHP options/info functions
Bug description: browscap.ini is out of date returns wrong info for IE6.0 and above
Description:
The browscap.ini file is out of date. The highest Microsoft browser
version supported is IE5.0
When it encounters IE6.0 and above it returns erronous info. Calims it's
a netsacpe 4.0 browser that does not support vbscript.
IE 6 has been available for over 1 year. this would imply that other
browsers are also out of date.
This may cause existing code to break.
Reproduce code:
---
?php
echo $_SERVER['HTTP_USER_AGENT'] . hr /\n;
$browser = get_browser();
foreach ($browser as $name = $value) {
echo b$name/b $value br /\n;
}
?
Expected result:
correct info for IE 6.0
should be the same as for IE 5.0
Actual result:
--
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
--
browser_name_regex Mozilla/4\.0.*
browser_name_pattern Mozilla/4.0*
parent Netscape 4.00
browser Netscape
version 4.00
majorver 4
minorver 00
frames 1
tables 1
cookies 1
backgroundsounds
vbscript
javascript 1
javaapplets 1
activexcontrols
beta 1
--
Edit bug report at http://bugs.php.net/?id=26913edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26913r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26913r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26913r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26913r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26913r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26913r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26913r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26913r=support
Expected behavior: http://bugs.php.net/fix.php?id=26913r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26913r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26913r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26913r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26913r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26913r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26913r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26913r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26913r=float
#26913 [Opn]: browscap.ini is out of date returns wrong info for IE6.0 and above
ID: 26913
User updated by: codeslinger at compsalot dot com
Reported By: codeslinger at compsalot dot com
Status: Open
Bug Type: PHP options/info functions
Operating System: All
PHP Version: 4.3.4
New Comment:
er, umm, did I make a bad assumption here??
I am assuming that the browscap.ini is installed by php??
But I just noticed that it is actually in the inetsrv folder.
Platform = Win98 with PWS, this is my first time installing php, so
please send your flames to dev/null
Thanks,
These appear to be the correct values for IE 6.0 created by a simple
hack of the IE5.0 info
; IE 6.0
[IE 6.0]
browser=IE
Version=6.0
majorver=6
minorver=0
frames=True
tables=True
cookies=True
backgroundsounds=True
vbscript=True
javaapplets=True
javascript=True
ActiveXControls=True
Win16=False
beta=True
AK=False
SK=False
AOL=False
Update=False
[Mozilla/4.0 (compatible; MSIE 6.*; Windows 95*)]
parent=IE 6.0
platform=Win95
beta=True
[Mozilla/4.0 (compatible; MSIE 6.*; Windows 98*)]
parent=IE 6.0
platform=Win98
beta=True
[Mozilla/4.0 (compatible; MSIE 6.*; Windows NT*)]
parent=IE 6.0
platform=WinNT
beta=True
[Mozilla/4.0 (compatible; MSIE 6.*)]
parent=IE 6.0
Previous Comments:
[2004-01-14 19:31:23] codeslinger at compsalot dot com
Description:
The browscap.ini file is out of date. The highest Microsoft browser
version supported is IE5.0
When it encounters IE6.0 and above it returns erronous info. Calims
it's a netsacpe 4.0 browser that does not support vbscript.
IE 6 has been available for over 1 year. this would imply that other
browsers are also out of date.
This may cause existing code to break.
Reproduce code:
---
?php
echo $_SERVER['HTTP_USER_AGENT'] . hr /\n;
$browser = get_browser();
foreach ($browser as $name = $value) {
echo b$name/b $value br /\n;
}
?
Expected result:
correct info for IE 6.0
should be the same as for IE 5.0
Actual result:
--
Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)
--
browser_name_regex Mozilla/4\.0.*
browser_name_pattern Mozilla/4.0*
parent Netscape 4.00
browser Netscape
version 4.00
majorver 4
minorver 00
frames 1
tables 1
cookies 1
backgroundsounds
vbscript
javascript 1
javaapplets 1
activexcontrols
beta 1
--
Edit this bug report at http://bugs.php.net/?id=26913edit=1
