Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96591 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52928 invoked from network); 24 Oct 2016 13:40:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Oct 2016 13:40:06 -0000 X-Host-Fingerprint: 137.50.156.90 oa-edu-156-90.wireless.abdn.ac.uk Received: from [137.50.156.90] ([137.50.156.90:26832] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/9D-28528-43F0E085 for ; Mon, 24 Oct 2016 09:40:05 -0400 Message-ID: <2A.9D.28528.43F0E085@pb1.pair.com> To: internals@lists.php.net References: <2cab4219-5128-7493-c604-5772534743ea@mabe.berlin> Date: Mon, 24 Oct 2016 14:40:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: <2cab4219-5128-7493-c604-5772534743ea@mabe.berlin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 137.50.156.90 Subject: Re: [PHP-DEV] strtod and NaN vs. zero From: ajf@ajf.me (Andrea Faulds) Hi, Marc Bennewitz wrote: > > But I'm still curious why casting any non numeric string results in the > valid number float(0) where there is a special value in floating point > numbers declared to represent not a number values. Because that's what C's strtod() does, and it's also what (int) does (because that's what C's strtol()) does. There'd be an argument for using NaN, sure, but it wouldn't be consistent with the rest of the language. Generally, PHP assumes that a string with no leading digits has the number value of zero. This is true not only in (int) and (float) casts, but also in generic number coercion operations, like with +, -, *, / and **. To change the behaviour of (float) here would be to introduce a new inconsistency to PHP. If we go for NaN everywhere, then we introduce a different problem: (int) should return an integer, and the generic number coercions prefer giving you an integer rather than a float if appropriate. Producing a NaN here would mean you'd now get an int rather than a float, and would cause a cascading change in operation result types which could lead to previously working code now throwing lots of E_WARNINGs or TypeErrors (NaN is not accepted for integer type declarations in weak mode, and all floats are not accepted for integer type declarations in strict mode). Thanks. -- Andrea Faulds https://ajf.me/