Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77628 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76871 invoked from network); 25 Sep 2014 14:43:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Sep 2014 14:43:29 -0000 Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.41 mail-wg0-f41.google.com Received: from [74.125.82.41] ([74.125.82.41:57135] helo=mail-wg0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/51-00789-01A24245 for ; Thu, 25 Sep 2014 10:43:29 -0400 Received: by mail-wg0-f41.google.com with SMTP id k14so8117658wgh.24 for ; Thu, 25 Sep 2014 07:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WU3j4cIgQTgGgqaXQkLrNvxBOMOVg1UXYzNgme3pf/w=; b=gEqyWT8FY5s/MW53NxIKeFZE0tO8LQseDHJ1O9NUZjKymiGusMG0LfIBooaR6cjpAY Y6sDI1agXQIdA9D9q71MZ7AD5JZs5nSBEiZJQp1MTsbXJyH6wsZFN8sn7GykhSoc2cgu vDNSoYrh08rcf+CzEMT0ahIb3zDhnA6NRv6IicS8hqR+zrBj7M80lqh0YFj/QGUb//rC KOoIc2Y16gpKXbQqvN3B54QBJEzwbMT8DCOr8QoNf70SPCJaEFp9GtKeuDkmd+i6oAJt 70/Lu9hVS9d0Mm1KjetMvm96lWOY0j+z6eouE4CcBMR6ZhOUNGHLNwGRwCsO2hPDkCUC +5KA== X-Received: by 10.194.185.112 with SMTP id fb16mr15568495wjc.91.1411656206079; Thu, 25 Sep 2014 07:43:26 -0700 (PDT) Received: from [192.168.0.177] ([62.189.198.114]) by mx.google.com with ESMTPSA id pn5sm2965998wjc.4.2014.09.25.07.43.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 07:43:25 -0700 (PDT) Message-ID: <54242A0C.3000309@gmail.com> Date: Thu, 25 Sep 2014 15:43:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "internals@lists.php.net" References: <07153B91-E12F-4B16-ADD7-86CFC75C4642@ajf.me> <54220EB4.60001@sugarcrm.com> <6A21F4EF-476E-476C-A64B-246B8929172B@ajf.me> <5422DD87.80109@gmail.com> <568C0F03-B23B-43FC-963D-6D0D23405E9D@ajf.me> <54230209.2050406@sugarcrm.com> <54233C70.3060604@gmail.com> <54236D16.3070401@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] ZPP Failure On Overflow From: rowan.collins@gmail.com (Rowan Collins) Andrea Faulds wrote (on 25/09/2014): >> No bogus value ever gets to a function - it always gets INT_MAX on >> > overflow. If INT_MAX is harmful for this function, this change does not >> > help as you could still pass INT_MAX and this change would not do anything. >> > No it won't. Normally it truncates (module), only some functions cap. I saw that in the RFC, and thought it rather odd that a more sane implementation already exists, but functions have to opt in to use it. I thought perhaps it was a side-effect of something else, but README.PARAMETER_PARSING_API doesn't list any other difference between "l" and "L": > l - long (long) > L - long, limits out-of-range numbers to LONG_MAX/LONG_MIN (long) What was the original motivation for functions to have that choice? -- Rowan Collins [IMSoP]