Re: [RFC] ZPP Failure On Overflow
| From: | Rowan Collins | Date: | Thu, 25 Sep 2014 14:43:24 +0000 |
| Subject: | Re: [RFC] ZPP Failure On Overflow | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77628@lists.php.net to get a copy of this message | ||
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.
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":No it won't. Normally it truncates (module), only some functions cap.
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]