Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110802 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 30527 invoked from network); 1 Jul 2020 15:37:37 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jul 2020 15:37:37 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BE66D1804F8 for ; Wed, 1 Jul 2020 07:26:49 -0700 (PDT) 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,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) (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, 1 Jul 2020 07:26:49 -0700 (PDT) Received: by mail-ej1-f47.google.com with SMTP id y10so24941047eje.1 for ; Wed, 01 Jul 2020 07:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RxOnBx0zg0TC4493clVX49Lc20590mUu3ujfNmSpF4I=; b=MeoPjXsrg5n5GPOxQ5x2R6SMmaW/WHG2duClhODP8JUU7bwyLF/VaAKzKNCniGNnML O6kEzR7Qp4Okty3AvAQOQ8lUdaDbdvMAWG9Z8qi2po41LIZPEKwDx6E9+9ncBhCne02Q p5DTzPKy9tkSurVQqwXUOlGC8vdlZSY/Wrd7nRUOmkIsd7KD8d3Q1TTX5ggiMGnlkgtw NCMsyGHFSmFQrz+wJfvjnOl+FYv6VzJSm0wK8rXv6U8DsZMofiPDutxghfeKteMl9OTS V2N51In7DVKiiwMeGIUPsDDLbfqxWzkJfUS+YL4YRll6G6iQHeY0bILeUmpaG977VCr7 5Fwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RxOnBx0zg0TC4493clVX49Lc20590mUu3ujfNmSpF4I=; b=Fw8/bpeIXTRSF6LdCRUV1GaQFATO1rtoNuJPQYV2PWZbtIKG7rO+SeZBP8KuoDGaJD OaMAdLhojiFEcoSuaAnjgA+n6WAYFIAKTQmZg+j6ri9MTG43JByEXjIZ/3b6foxIe7xq rJGphDQW3pM8rxU+oQfm7BXinGVYUfPX8+M5uXICgxUhVd75oMXziQYU4OO0y3xeDbeT cKNgDtv88oBCxbvNH7JTBlFwosIwv5PbrjvuG0k4ysKNIpQOWfGe0DBNxxxMbDiAdPe7 SX/JYC1PECoJ4psnyerUIgHrPploMLkSLZYf9zQRPLu+ZE8oGMpKrsB1dsfKklmBZnrX FPAg== X-Gm-Message-State: AOAM5311hisUSKH/+Na6LhtTF1YX96LPOvYIk2a++E1wvVJ4qvyaKe1y 9X8nn5WKgjcs2zyUxG9O91kB6X7rXJiBHiWRVzmnj+cY X-Google-Smtp-Source: ABdhPJzusUVFWNfhVjfFH2Pd4Fp+m6yqGxfMCsORQf9X84T2KrhGuyXkEDw9DLAnqJRtYLfb9gqxfkk8ND2O7jqhJFY= X-Received: by 2002:a17:906:1499:: with SMTP id x25mr22831420ejc.406.1593613607155; Wed, 01 Jul 2020 07:26:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 1 Jul 2020 16:26:35 +0200 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000f6be3e05a9621465" Subject: Re: [PHP-DEV][RFC] Saner numeric strings From: george.banyard@gmail.com ("G. P. B.") --000000000000f6be3e05a9621465 Content-Type: text/plain; charset="UTF-8" Hello again, While reviewing the implementation Nikita spotted a peculiar behaviour that PHP currently has in regards to string offsets. The offset is validated using the is_numeric_string but integer representation of it is computed using an explicit int cast, this is what leads to the E_NOTICE in a roundabout way. Therefore, a string offset access such as $str['2str'] or $str['2.5'] would still evaluate to 2 under the current implementation but would generate an E_WARNING "Illegal string offset". The question becomes should such string offsets evaluate to 0 or not. The answer isn't that straight forward as a float index like 14.5 would also emit the same warning but evaluate to 14. I see 3 options: 1. Keep the current behaviour which emit the E_WARNING "Illegal string offset" and use the explicit int cast for both types of offsets ( '2str' and '2.5'), which would bring the behaviour of leading integer numeric strings in line with the one for float numeric strings. 2. Emit the E_WARNING "Illegal string offset" and evaluate to 0 for offsets like '2str', and emit the E_WARNING "String offset cast occurred" for float numeric strings like '2.5' 3. Emit the E_WARNING "Illegal string offset" and evaluate to 0 for non-numeric integer strings. As this is relatively tricky and all of the options have some change in behaviour compared to PHP 7 feedback would be very much appreciated. I'll amend the RFC to detail this behaviour. Best regards George P. Banyard --000000000000f6be3e05a9621465--