Re: [RFC] 64 bit platform improvements for string length and integer

From: Date: Sat, 11 Jan 2014 16:08:26 +0000
Subject: Re: [RFC] 64 bit platform improvements for string length and integer
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-71068@lists.php.net to get a copy of this message
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

« previous php.internals (#71068) next »