On Sat, Jan 11, 2014 at 3:29 PM, Anatol Belski <ab@php.net> wrote:
>
> yep, that's exactly how it performs till now in the mainstream, just
> replace ZEND_INT_MAX with LONG_MAX. Adding a warning to every such case
> would cause a warning flood in many PHP apps, guaranteed :) Whereby it
> might be ok for debug mode maybe, I wouldn't do it as I can't remember any
> WTFs about the behavior.
>
>
I meant adding warning only for overflow cases. Values in existing apps
can't be bigger than LONG_MAX so I don't see how it could cause warning
flood in the current PHP apps. I don't even think that users will be often
using such a big values after the 64bit changes.
The thing is that if I use value bigger than LONG_MAX after 64bit changes
and I pass it to the function defined in extension that does not support it
(use "l" in zpp), then I rather see warning than unexpected rounding to
LONG_MAX... There is no way how to find out (except looking to the ext
sources) that the big values are not supported. If I get warning, I can fix
it in the code straight away...
The another thing is that this checking needs to be done by other libraries
wrappers after getting parameters because the most libraries using smaller
types. That was exactly what I did when I worked on openssl ext for 64bit
and I will need to do it in my fann and crypto extension. There are bunch
of other extensions that will need to do it too (for example imagick). The
difference with openssl changes is that the BC will need to be kept. I am
sure that if warnings were already in zend_parse_arg_impl, then the work
for supporting 64bit branch would much easier for me and other PECL
extension maintainers...
Cheers
Jakub