Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105646 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 72522 invoked from network); 8 May 2019 21:54:45 -0000 Received: from unknown (HELO mail-qk1-f174.google.com) (209.85.222.174) by pb1.pair.com with SMTP; 8 May 2019 21:54:45 -0000 Received: by mail-qk1-f174.google.com with SMTP id d4so1283094qkc.9 for ; Wed, 08 May 2019 11:58:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EsTkkcwlXLF2ztM5tJ+Uy0JmwTJbSfBT2W64Vsk+igc=; b=ac9Al55NaIsZU3qJKoRnp9AOU/J48dLzHc5Az2ePdue3/3Fr3QNpFgvQpYgrMr23CE EmkeH3zdyOeSMhYYwZ8mVfEFhuk3igz4BmSEUh1uZexrBIZ+2Slcu/Kbe5EoMgGaq555 +62kAuPCTOD0fXA3C0MWoaMuHo5SmFymjOrhM17bNlrGJQlx7Ht1K6pIEh7Jl0kJTjAK rRmXfw1dUk5QD5vDFkaNlwHVUg8RtH2bC0ggQO1XafEKiLNYhTBsEtobrjuzRh5lQqL1 b/mrgnsNQzJsw6PjhQ9zP/H6wdqWBTpod+hnjJZJM5v8TNGyimeR6kFHG8CYmO2eQ4gl CQyQ== X-Gm-Message-State: APjAAAViuRKK4umHxnJHvWHHCByQ13Sj4NO6tQFckCbCVPgXzDA662cc 35u+G17+Qkx7G43wfXkUvsp+KOX3LiGqsjZWeodxzLaiv7TgbQ== X-Google-Smtp-Source: APXvYqxLAVp27MoDOp7Ve044S8omkMIkLtE7aPnv3ZF8xPF5td8IvS1dzuBGcGga5/6hgE2W3QpOYD13HL89L5wTvIg= X-Received: by 2002:a37:943:: with SMTP id 64mr2775340qkj.80.1557341937298; Wed, 08 May 2019 11:58:57 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 8 May 2019 13:58:46 -0500 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000f78470058864ecd8" Subject: zend_atol() and zend_atoi() From: pollita@php.net (Sara Golemon) --000000000000f78470058864ecd8 Content-Type: text/plain; charset="UTF-8" I fell down a WTF hole today that led me to zend_atol(). The end result is the PR which I'd like to present for discussion (I'll add tests before I push anything, though it might necessitate a vote). https://github.com/php/php-src/pull/4132 The issue is explained in the commit message, but I'll copy here: zend_ato[il] don't just do number parsing. They also check for a 'K', 'M', or 'G' at the end of the string, and multiply the parsed value out accordingly. Unfortunately, they ignore any other non-numerics between the numeric component and the last character in the string. This means that numbers such as the following are both valid and non-intuitive in their final output. - "123KMG" is interpreted as "123G" -> 132070244352 - "123G " is interpreted as "123 " -> 123 - "123GB" is interpreted as "123B" -> 123 - "123 I like tacos." is also interpreted as "123." -> 123 This diff primarily adds warnings for these cases when the output would be a potentially unexpected, and unhelpful value. Additionally, several places in php-src use these functions despite not actually wanting their KMG behavior such as session.upload_progress.freq which will happily parse "1 banana" as a valid value. For these settings, I've switched them to ZEND_STRTOL which preserves their existing /intended/ behavior. - It won't respect KMG suffixes, but they never really wanted that logic anyway. - It will ignore non-numeric suffixes so as to not introduce new failures. We should probably reexamine that second bullet point separately. Lastly, with these changes, zend_atoi() is no longer used in php-src, but I left it as a valid API for 3rd party extensions. Note that I did make it a proxy to zend_atol() since deferring the truncation till the end is effectively the same as truncation during multiplication, but this avoid code duplication. I think we should consider removing zend_atoi() entirely (perhaps in 8.0?) and rename zend_atol() to something reflecting it's KMG specific behavior. -Sara --000000000000f78470058864ecd8--