AW: [PHP] PHP is Zero
| From: | BUSCHKE Daniel | Date: | Thu, 13 Jun 2013 09:44:03 +0000 |
| Subject: | AW: [PHP] PHP is Zero | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-321383@lists.php.net to get a copy of this message | ||
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.
>> 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)
For 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