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

On Tue, 6 May 2014, Anatol Belski wrote: > I would sincerely invite everyone to the resurrected > str_size_and_int64 RFC discussion. > > I propose the discussion to last for one week as allowed by the voting > RFC because this topic has already been discussed to death previously > (any objections?). As no userland change is introduced, the discussion > would end and the voting would start on May 13th with 50%+1 votes > requirement. > > https://wiki.php.net/rfc/size_t_and_int64_next I see this still says "The usage of long datatype continues on 32 bit platforms." — do I understand correctly that on 32bit platforms, there won't still be a 64bit integer in PHP and that this "only" makes 64bit integers work on the Windows LLP64 model? Or are they still 32bit integers there? Under "Accepting values with zend_parse_parameters()" “l” “i” to accept integer argument, the internal var has to be declared as php_int_t (inside PHP) or zend_int_t (inside Zend) “L” “I” to accept integer argument with range check, the internal var has to be declared as php_int_t (inside PHP) or zend_int_t (inside Zend) Using l and I is going to be major confusing and incredibly hard to spot. "'l', 'L', 's', 'p' parameter formats aren't available anymore" That means that every zpp call now needs to have an #ifdef around it to support post-this-patch and pre-this-patch PHP versions, as well as around their variable declarations. I'm afraid that will result in a huge mess, so we should look at this again. Under "Example on accepting parameters with zpp" You have: zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "iISP" But why is both i and I allowed (or did I misread the Old/New before?) If so, then my comment on i, l, I is already valid :-) Under "Example on printf specs usage" You have: php_error_docref(NULL TSRMLS_CC, E_WARNING, "Value '" ZEND_INT_FMT "' is out of range", i0); Using that macro there feels really unnatural, and many C developers will not bother to figure out that they use that, of course ,because they are familiar with "%d" and "%l". And similarly under "Example on printf specs usage (no BC)" for: "Value '%pd' is out of range", i0 The new macros that you use in the example for "char *dup_substr(zval *s, zval *i)" also infer that all those accesses need to have a big #ifdef around stuff to support multiple versions. Again, making it a major pain for extension developers to support pre- and post-patch PHP versions. I'm afraid with all those concerns, I will have to vote "no". cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine