Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113354 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 64358 invoked from network); 3 Mar 2021 18:31:18 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Mar 2021 18:31:18 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 134BC1804C3 for ; Wed, 3 Mar 2021 10:21:52 -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=-0.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) (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 ; Wed, 3 Mar 2021 10:21:51 -0800 (PST) Received: by mail-pg1-f182.google.com with SMTP id a23so7178836pga.8 for ; Wed, 03 Mar 2021 10:21:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=fgiMr1MYNtzy3VTzsXjdNZfimBPDbnnlAB1WnPYskQE=; b=ZkwJzy/BGsFnML1Gsh2ohsTdPCf0ypqRrcql06IBkG5vu0A2FN/5+WkBUCpJl+fxGy aNDYjVksuRjRevu+c6XjqbsGJSWk0dl6hnF7KaeKaQ3Ll5QE6xLi1SfCirMcaGWJcCpg QSXFcMmzLYCnwrRgyzrxKhBGCOOlsLtz7VNaIQ8UnI8Px6eVXjmAXfxGWeGJFVIXZx3R X1BgKAajY++W2Q2d804vbGhegPY0SsSX7UXa5txwd2pVksKeMjmmbUqm9Rm7dRqFmB9/ 9mHnkHcpkO+3JAEfakETw650Jzj8ZQgHjSsLNFECn/EtTiTB2BuMYvaz+Um4OS0vW9H0 Y4MQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fgiMr1MYNtzy3VTzsXjdNZfimBPDbnnlAB1WnPYskQE=; b=DfRsptPceM1NOUvVXy8H5EewwWiHSG+eHLJUhAocMfdfTiw/LPSCsDOjcaSBN0zZxh vrwcgp6H0aicGCJcW7bmWeDSffSRgyZFHGnzxlRsjFAjssm//kq8pZ2rGq1Ye2uqjHwU a9wke3p8cuc9cy7QjmmScPE8HSWAhAVuSY7dmEl74hJ9WyluXNfd+7gT+C2SJoCFG2A0 hsolL8MBFk13yU+pS5VcVn3X68qCXOxtF2vyklWFE3i+ZtaD0n/zBJPAvwt45sgoV9xg cEJVCrKI18GDSfSMFE5l27RUNNrXbuAh2lg80m13xOAZ1OwylczAbSDwRSr1a8qCfSzq qC5w== X-Gm-Message-State: AOAM531x8o2Ww3tLf8i8nouefBhDXH59NDjrED639ivLbdJwqztWO476 0afEaOZLBZ5PCsaulUhRXF6tVrlQf48S X-Google-Smtp-Source: ABdhPJz6twC+Qd1gl/dkivgHZlAQZa1VxrFX6tr9v1WPlWdChNGiIIY8Q4fY/hQ8KQKMzkRBv9nEPw== X-Received: by 2002:aa7:9a86:0:b029:1ee:70dd:c44e with SMTP id w6-20020aa79a860000b02901ee70ddc44emr102259pfi.56.1614795708982; Wed, 03 Mar 2021 10:21:48 -0800 (PST) Received: from ip-192-168-154-171.us-west-2.compute.internal (ec2-44-226-106-152.us-west-2.compute.amazonaws.com. [44.226.106.152]) by smtp.gmail.com with ESMTPSA id q66sm6656832pja.27.2021.03.03.10.21.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Mar 2021 10:21:48 -0800 (PST) To: internals@lists.php.net References: Message-ID: Date: Wed, 3 Mar 2021 12:21:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; 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-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] Don't compare zero exponentials in strings as equal From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > PHP's == comparison semantics for strings have a peculiar edge-case, where > comparisons of the form "0e123" == "0e456" return true, because they are > interpreted as floating point zero numbers. This is problematic, because > strings of that form are usually not numbers, but hex-encoded hashes or > similar. This particular argument makes sense, but in more generic sense I feel it leads us to a dangerous path of implying it's ok to use "==" to compare strings, because we'll take care of the corner cases. Which I think is wrong to imply because there are so many corner cases where it still doesn't work and probably never will. I mean, "000" == "0000000" is still true. "010" == "0000010" is still true. "1e23" == "001e023" is still true. Nobody who applies == to strings and expects it to work out as stri g comparison is doing the right thing. If you apply == to hex-encoded hashes, that code is fubar, and fixing one particular corner case won't rescue it. So I wonder if fixing one particular corner case while leaving many others in would do much. -- Stas Malyshev smalyshev@gmail.com