View Issue Details

IDProjectCategoryView StatusLast Update
0000105XdebugFeature/Change requestpublic2004-11-27 20:28
Reporter0x33Assigned Toderick 
PrioritynormalSeveritytrivialReproducibilityalways
Status resolvedResolutionno change required 
Product Version 
Target VersionFixed in Version 
Summary0000105: Fancy var_dump function vs Var_Dump class
DescriptionHi 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:
--------------
array
  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> 
    array
      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>
Additional InformationOr would it be possible, before the following two lines in xdebug.c :

    zend_hash_find(EG(function_table), "var_dump", 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