# PHP6 & floatval() BC issue - Thread: https://externals.io/message/35945 - Original archive: https://news-web.php.net/php.internals/35945 - Started by Christian Schneider on 2008-03-04T14:17:01+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #35945 — Christian Schneider — 2008-03-04T14:17:01+00:00 URL: https://externals.io/message/35945#35945 Hi all, playing around with PHP 6 I noticed the following BC issue: floatval("4.2foo") gives an `E_NOTICE` "A non well formed numeric value encountered". The type casting (float)"4.2foo" still works as before. The change was introduced with the conversion of `floatval()` to zend_parse_parameters with revision 1.43 of ext/standard/type.c on 2006/09/24 18:23:47 by pollita (PHP6 Updates). In my opinion `floatval()` should be restored to the previous behavour because a) the documentation for floatval itself uses a non well formed value in the example and b) to keep it the same as type casting to (float). Or would the proper procedure for me be to open a ticket in the bug tracker? - Chris --- ## #35946 — Pierre Joye — 2008-03-04T14:28:57+00:00 URL: https://externals.io/message/35945#35946 · In reply to: #35945 Hi Christian, On Tue, Mar 4, 2008 at 3:17 PM, Christian Schneider wrote: > Hi all, > playing around with PHP 6 I noticed the following BC issue: > floatval("4.2foo") gives an `E_NOTICE` "A non well formed numeric value > encountered". The type casting (float)"4.2foo" still works as before. > > The change was introduced with the conversion of `floatval()` to > zend_parse_parameters with revision 1.43 of ext/standard/type.c on > 2006/09/24 18:23:47 by pollita (PHP6 Updates). > > In my opinion `floatval()` should be restored to the previous behavour > because a) the documentation for floatval itself uses a non well formed > value in the example and b) to keep it the same as type casting to (float). If we keep this behavior (I don't understand this change), it would be better to change (float) to behave like floatval, to be consistent. If we keep the (float) casting instead, then I agree with you, floatval notice should be removed. I prefer the second solution as it reduces the pain to migrate, if one likes to have strict validation or conversion it can rely on ext/filter. > Or would the proper procedure for me be to open a ticket in the bug tracker? It would help to do not forget this problem yes :) Thanks for your report! -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36532 — Christian Schneider — 2008-03-26T11:27:17+00:00 URL: https://externals.io/message/35945#36532 · In reply to: #35946 Pierre Joye wrote: > On Tue, Mar 4, 2008 at 3:17 PM, Christian Schneider > wrote: > > […] > > > […] > > It would help to do not forget this problem yes :) I opened a bug report yesterday as you recommended and it was marked bogus. As I never got another answer apart from yours here I wonder if this BC break is thus intentional and what the motivation behind it is. Do we have to change all `floatval()` to (float) to be safe from suprises from PHP 6? - Chris --- ## #36534 — Pierre Joye — 2008-03-26T11:55:29+00:00 URL: https://externals.io/message/35945#36534 · In reply to: #36532 On Wed, Mar 26, 2008 at 12:27 PM, Christian Schneider wrote: > Pierre Joye wrote: > > […] > > > […] > > > […] > > I opened a bug report yesterday as you recommended and it was marked > bogus. As I never got another answer apart from yours here I wonder if > this BC break is thus intentional and what the motivation behind it is. > > Do we have to change all `floatval()` to (float) to be safe from suprises > from PHP 6? I don't see why it has been bogufied. It should be either fixed (as you described) or the documentation has to be updated (move the bug to the doc category). Which # is it? -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36535 — Felipe Pena — 2008-03-26T12:01:43+00:00 URL: https://externals.io/message/35945#36535 · In reply to: #36534 Em Qua, 2008-03-26 às 12:55 +0100, Pierre Joye escreveu: > I don't see why it has been bogufied. It should be either fixed (as > you described) or the documentation has to be updated (move the bug to > the doc category). > > Which # is it? Re-opened. http://bugs.php.net/bug.php?id=44533 -- Regards, Felipe Pena. --- ## #36558 — Stanislav Malyshev — 2008-03-26T19:48:07+00:00 URL: https://externals.io/message/35945#36558 · In reply to: #36535 > > […] > > Re-opened. http://bugs.php.net/bug.php?id=44533 So it's just gives additional notice? That's a bit strange since intval doesn't, and neither does (float). I see no reason for `floatval()` to be different from others. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36585 — Christian Schneider — 2008-03-26T22:45:48+00:00 URL: https://externals.io/message/35945#36585 · In reply to: #36558 Am 26.03.2008 um 20:48 schrieb Stanislav Malyshev: > > […] > > So it's just gives additional notice? That's a bit strange since > intval doesn't, and neither does (float). I see no reason for > `floatval()` to be different from others. I agree but the reason it is different right now is that floatval has been changed to use zend_parse_parameters(). I'm not sure how this is best solved as I didn't want to revert it back to zend_get_parameters_ex(), otherwise I would have provided a patch. - Chris