Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113389 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 3492 invoked from network); 4 Mar 2021 19:36:00 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Mar 2021 19:36:00 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C149C1804C0 for ; Thu, 4 Mar 2021 11:26:49 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 4 Mar 2021 11:26:49 -0800 (PST) Received: by mail-wr1-f51.google.com with SMTP id v15so28942766wrx.4 for ; Thu, 04 Mar 2021 11:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=fS2YN5xNkN9KforkGsKttJf8eLKng4+SPsRIQ4UtAQQ=; b=evqmPB8N3PQIyIdQLurPGS94pTLswPTz/Y3/q9Da+TH5a/1RSS3RA+ScdFdoBduHTj LOQL3fLrR4r8DPFuUjCelp7Q3IX44w6qEBmQLLR7LRoYRwEm6zhrp1aa3H0KwQXQnz5P VGIpGqfGRI9c3HiSqY0BX/8PgQ/11SHMk6TSuNHQZDAfO9Vj0bC1DZR8d7ZcBMK9PAkT XB9/qvNJExilcrG6udCCnTpHhcMQ169o5reMU+y5Vj+oYUwXart5yWOqNE1I2ns2HbIl gXMGMzKLmc/XssxzUN2/tkyxkZKDnL4wv5nsNJ4zog6a77iByl02C+n3d5gyXzhbBPMm wHag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fS2YN5xNkN9KforkGsKttJf8eLKng4+SPsRIQ4UtAQQ=; b=nUmBO7OHv7DotC8ciPKO3zmrsFf/MVdKTmmto2Rx1u5O4RsjxAKBa/gzjmDUCUdi7+ wbdxy5xqDNRP96MzLy2cW+oteR+N+9iu4Nwb8BhqXTXXw+lvVhshaiCtz8Kk9UaKK8q8 BKLrfruXzGAnw5MKpGlCXlLo8X8czOt4/XAF9zL5n+wEcjEBq0tO0spoasPuBeX1mxI9 EoDmLU6PqWTOW2LZuDoHURF7P42KzQaPQ4bweUlNhHS3heANACSssLTC05RVAHbmYdRC 8ReBEBmAjPnlbrejnJeJUxnJWWW3+FIPBMOetsKBb8daefpld1K2VkjDUY+wk5UWqciZ VKiA== X-Gm-Message-State: AOAM530EzSsY7rWnL3aSLmnEKDu3+2q8lobxJUA86aSCkOr2jhHdYWEm vmqidtGJ10e2x1jknxqdLaSAF1B1WeQ= X-Google-Smtp-Source: ABdhPJwhg2rQQo3X4XBnN2mwiYFfgToX7IS+edntzTuWRNTzxbcaQVo5fFNJmb5+0QID+lPgeQE9dQ== X-Received: by 2002:adf:ea87:: with SMTP id s7mr5674478wrm.109.1614886006808; Thu, 04 Mar 2021 11:26:46 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id p190sm636252wmp.4.2021.03.04.11.26.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Mar 2021 11:26:46 -0800 (PST) To: PHP internals References: <424A5E98-2110-4AFE-9C53-8636A6140313@benramsey.com> Message-ID: <6b639f72-ead5-0725-a32d-79b6f1bc2da4@gmail.com> Date: Thu, 4 Mar 2021 19:26:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal From: rowan.collins@gmail.com (Rowan Tommins) On 04/03/2021 13:17, Nikita Popov wrote: > > A disadvantage of narrowing the definition in such a fashion is that > it introduces a discrepancy with (float) casts. I believe these > currently recognize the same values, with the exception that (float) > discards trailing garbage. I don't think that's a big problem; as you say, explicit casts are already more lax than implicit ones, and that's always going to be the case in some sense, because they never "fail". Opinions may vary, though. > > Another disadvantage is that exponential notation is commonly returned > for large numbers by various data source -- e.g. if you stored a large > float in a database, I'd expect you'd get it back in exponential > notation (if you get it back as a string). This means that your code > could suddenly break because the range of a value passes some > heuristic threshold for how it gets printed. That may be a more compelling reason, at least given backwards compatibility requirements. I don't know how common that is, but it certainly sounds plausible. Regards, -- Rowan Tommins [IMSoP]