# Make debug_zval_dump prints int as long - Thread: https://externals.io/message/87264 - Original archive: https://news-web.php.net/php.internals/87264 - Started by Xinchen Hui on 2015-07-24T08:21:04+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #87264 — Xinchen Hui — 2015-07-24T08:21:04+00:00 URL: https://externals.io/message/87264#87264 Hey: I made a small PR about changes output of some types name in debug_zval_dump, to make it behavior consistently with var_dump. https://github.com/php/php-src/pull/1434 2 things are changed: 1. print int instead of long 2. print float instead of double. RM and me are worrying about this will break some APPs unit tests .. anyway, welting doesn't find any in github.. so, is there any objections to merge this into PHP7.0? thanks -- Xinchen Hui @Laruence http://www.laruence.com/ --- ## #87269 — Pierre Joye — 2015-07-24T12:17:18+00:00 URL: https://externals.io/message/87264#87269 · In reply to: #87264 > > Hey: > > I made a small PR about changes output of some types name in > debug_zval_dump, to make it behavior consistently with var_dump. > https://github.com/php/php-src/pull/1434 > > 2 things are changed: > > 1. print int instead of long > 2. print float instead of double. > > RM and me are worrying about this will break some APPs unit tests > .. anyway, welting doesn't find any in github.. > > so, is there any objections to merge this into PHP7.0? Some consistencies changes in debug functions are fine imho. Cheers, Pierre --- ## #87283 — Stanislav Malyshev — 2015-07-25T00:38:34+00:00 URL: https://externals.io/message/87264#87283 · In reply to: #87264 Hi! > I made a small PR about changes output of some types name in > debug_zval_dump, to make it behavior consistently with var_dump. > https://github.com/php/php-src/pull/1434 > > 2 things are changed: > > 1. print int instead of long > 2. print float instead of double. I think that's fine, it's a debug function, even says it in the name. Also pretty deep into engine internals. So I don't think is it a problem. Just add a note to UPGRADING. -- Stas Malyshev smalyshev@gmail.com --- ## #87285 — Rowan Collins — 2015-07-25T01:42:13+00:00 URL: https://externals.io/message/87264#87285 · In reply to: #87264 > Hey: > > I made a small PR about changes output of some types name in > debug_zval_dump, to make it behavior consistently with var_dump. > https://github.com/php/php-src/pull/1434 > That function desperately needs an updated manual page. The current one recommends using call-time pass-by-reference (impossible since 5.4), and the changes to zvals in PHP 7 make its behaviour completely different from anything in PHP 5. I've thought before that it might be best to simply deprecate it, because the only information it gives is a highly questionable refcount - though playing around, it seems to be less influenced by the act of calling the function in PHP 7. I'm also not convinced consistency with var_dump makes particular sense. If anything, it should be extended to more accurately reflect the internal representation, since that's it's claimed purpose. For instance, an IS_REFERENCE zval could be shown as such, with a separate refcount from the referenced value, so that you could follow along with the examples in this blog post: http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1 The current implementation just adds 1 to the target refcount, per this experiment: http://3v4l.org/NejOM Regards, -- Rowan Collins [IMSoP] --- ## #87287 — Christoph Becker — 2015-07-25T11:49:41+00:00 URL: https://externals.io/message/87264#87287 · In reply to: #87285 Rowan Collins wrote: > > > […] > > That function desperately needs an updated manual page. The current one > recommends using call-time pass-by-reference (impossible since 5.4), and > the changes to zvals in PHP 7 make its behaviour completely different > from anything in PHP 5. I agree that the manual page needs an update, but it seems that would result in an even more lengthy explanation of the caveats due to the different behavior under PHP 5 and PHP 7, respectively. > I've thought before that it might be best to simply deprecate it, > because the only information it gives is a highly questionable refcount > - though playing around, it seems to be less influenced by the act of > calling the function in PHP 7. It seems to me that the basic issue of `debug_zval_dump()` is that it is a function and not a language construct, so the refcounts are never "quite right". The variadic nature of the function may add to the confusion, see . > For instance, an IS_REFERENCE zval could be shown as such, with a > separate refcount from the referenced value, so that you could follow > along with the examples in this blog post: > http://nikic.github.io/2015/05/05/Internal-value-representation-in-PHP-7-part-1 > The current implementation just adds 1 to the target refcount, per this > experiment: http://3v4l.org/NejOM Apparently, this has been done deliberately for compatibility reasons[1]. [1] -- Christoph M. Becker --- ## #87289 — Rowan Collins — 2015-07-25T14:16:52+00:00 URL: https://externals.io/message/87264#87289 · In reply to: #87287 > I agree that the manual page needs an update, but it seems that would > result in an even more lengthy explanation of the caveats due to the > different behavior under PHP 5 and PHP 7, respectively. Well, the current manual page is invalid for any version of PHP which is currently maintained, since 5.3 is EOL, and 5.4 raises a fatal error for the first example. That actually simplifies things a little bit, because you don't need all the caveats about whether the variable is passed by reference or not, that's can just be a historical footnote. > It seems to me that the basic issue of `debug_zval_dump()` is that it is a > function and not a language construct, so the refcounts are never "quite > right". Agreed. > The variadic nature of the function may add to the confusion, > see . Oh, lord, I didn't realise that was even possible! > > > […] > Apparently, this has been done deliberately for compatibility reasons[1]. > > [1] > > Yeah, I spotted that comment, but compatibility with what, for what end? The refcounts given aren't the same between PHP5 and PHP7, and the current approach completely masks how many variables share an IS_REFERENCE zval, because it only ever increments the count by 1. If we're willing to change "long(42) refcount(1)" to "int(42)", then even the format of the output clearly isn't sacred, so why not throw in as much information as possible? If we're not going to make any attempt at accuracy, then rather than making cosmetic changes like "int" for "long", we should be adding an `E_DEPRECATED` flag and leaving the function to die quietly. Regards, -- Rowan Collins [IMSoP] --- ## #87591 — Christoph Becker — 2015-08-04T00:51:04+00:00 URL: https://externals.io/message/87264#87591 · In reply to: #87289 > > > […] > > Well, the current manual page is invalid for any version of PHP which is > currently maintained, since 5.3 is EOL, and 5.4 raises a fatal error for > the first example. > > That actually simplifies things a little bit, because you don't need all > the caveats about whether the variable is passed by reference or not, > that's can just be a historical footnote. I agree, but even then it's a bit tricky, and the doc team seems to be shorthanded currently. You may consider to give a helping hand. :) > If we're not going to make any attempt at accuracy, then rather than > making cosmetic changes like "int" for "long", we should be adding an > `E_DEPRECATED` flag and leaving the function to die quietly. I guess that might require an RFC. -- Christoph M. Becker