View Issue Details

IDProjectCategoryView StatusLast Update
0000105XdebugUncategorizedpublic2020-03-12 17:07
Reporter0x33 Assigned Toderick  
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionno change required 
Summary0000105: Fancy var_dump function vs Var_Dump class
Description

Hi Derick,

The fancy var_dump function, which overrides the default var_dump() in PHP, does not have the same kind of output than the default function : it produces an html dump, whereas the default function produces a plain text dump (without html tags).

The PEAR::Var_Dump package, whose I am the maintainer, closely depends on the output of the original var_dump() function to operate. And because the two results differ, the result of the Var_Dump class using your fancy replacement, does not produce the expected result (see bug http://pear.php.net/bugs/bug.php?id=2574).

I've seen in the changelog, and in xdebug.c that your function overrides the default PHP function. But in the online documentation, you don't explicitly tell that, because the xdebug_var_dump() function is logically used to do this job.

So I wanted to have your opinion to resolve this problem smoothly : do I need to take care of the result of your function in the Var_Dump class ; or do you think it could be possible to leave the original function as it is, perhaps with a configuration item telling if the user want to override or not the default var_dump function ?

Regards,
Frederic Poeydomenge


PHP Version 4.3.9-1.dotdeb.3
PHP API 20020918
PHP Extension 20020429
Zend Extension 20021010
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with
Xdebug v1.3.2

Reproduce code:

<?php
$a = array (1, 2, array ("a", "b", "c"));
var_dump($a);
?>

Expected result:

array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
array(3) {
[0]=>
string(1) "a"
[1]=>
string(1) "b"
[2]=>
string(1) "c"
}
}

Actual result:

<pre>
<b>array</b>
0 <font color='#777777'>=></font> <font color='#00bb00'>1</font>
1 <font color='#777777'>=></font> <font color='#00bb00'>2</font>
2 <font color='#777777'>=></font>
<b>array</b>
0 <font color='#777777'>=></font> <font
color='#bb00bb'>'a'</font>
1 <font color='#777777'>=></font> <font
color='#bb00bb'>'b'</font>
2 <font color='#777777'>=></font> <font
color='#bb00bb'>'c'</font>
</pre>

Additional Information

Or would it be possible, before the following two lines in xdebug.c :

zend_hash_find(EG(function_table), &quot;var_dump&quot;, 9, (void **)&orig);
orig->internal_function.handler = zif_xdebug_var_dump;

to create a link/pointer to the original var_dump() function (e.g. _xdebug_old_var_dump()) ?

That would allow to use your fancy var_dump function as usual, but also to call the old function by using something like this :

if (
extension_loaded('xdebug') and
function_exists('_xdebug_old_var_dump')
) {
$func = '_xdebug_old_var_dump';
} else {
$func = 'var_dump';
}

What do you think of this option ?
Regards

TagsNo tags attached.
Operating SystemDebian GNU/Linux
PHP Version5.0.2

Activities

0x33

2004-11-24 15:43

reporter   ~0000214

I'm sorry for the trouble.

I've just discovered that the original var_dump() function was called when the "html_errors" configuration option is set to "off", and I've taken that into account in the new release of the Var_Dump package.

In fact, everything is fine, and I think you can close this bug, as it is bogus.

Regards
Frederic Poeydomenge

derick

2004-11-27 20:28

administrator   ~0000215

As you said, not a bug, but a feature. Marking it as such.

Issue History

Date Modified Username Field Change
2004-11-20 19:11 0x33 New Issue
2004-11-24 15:43 0x33 Note Added: 0000214
2004-11-27 20:28 derick Status new => resolved
2004-11-27 20:28 derick Resolution open => no change required
2004-11-27 20:28 derick Assigned To => derick
2004-11-27 20:28 derick Note Added: 0000215
2020-03-12 16:56 derick Severity trivial => feature
2020-03-12 17:07 derick Category Feature/Change request => Uncategorized