Re: AW: [PHP] PHP is Zero
| From: | richard gray | Date: | Thu, 13 Jun 2013 10:12:46 +0000 |
| Subject: | Re: AW: [PHP] PHP is Zero | ||
| References: | 1 2 3 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-321384@lists.php.net to get a copy of this message | ||
On 13/06/2013 11:44, BUSCHKE Daniel wrote:
Hi, thanks for your answer. Especially the answer "42" made me laughing :) My "Why" questions should be understand as "Why must it be like that" questions.Cheers RichFor me it is not. PHP throws things away during conversion. In my opinion a language (compiler, interpreter whatever) should not do that. Never ever! Either it is able to convert the value or it is not. What about of returning "null" instead of "0" if the conversion is not perfect? So intval('F') could return NULL and intval('0') could return 0. Regards Daniel I think you will have to live with this or use another language for development - IMO it will never change because of the massive BC break that would be produced by changing the type juggling behaviour... of course you could always post an RFC to the dev/internals list if you want to take this further... good luck with that!On 13/06/13 08:59, BUSCHKE Daniel wrote: 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by throwing everything starting from "da08.." away.That's a very different proposition, and probably has more to do with word size: float is 32-bit, so only the first 32 bits are used and if anything else is found the conversion falls back to INF. To handle really big integers like 8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist library (or language)