[xdebug-dev] Bug 0000105: Fancy var_dump function vs Var_Dump class

From: <xdebug-dev[@]lists.xdebug.org>
Date: Sat, 27 Nov 2004 20:28:41 +0100

The following bug has been RESOLVED.
Reporter: 0x33
Handler: derick
Project: Xdebug
Bug ID: 105
Category: Feature/Change request
Reproducibility: always
Severity: trivial
Priority: normal
Status: resolved
Operating System: Debian GNU/Linux
PHP Version: 5.0.2
Xdebug Version: 1.3.2
Resolution: not a bug
Date Submitted: 2004-11-20 19:11 CET
Last Modified: 2004-11-27 20:28 CET
Summary: Fancy var_dump function vs Var_Dump class
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

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 ?

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:
$a = array (1, 2, array ("a", "b", "c"));

Expected result:
array(3) {
  array(3) {
    string(1) "a"
    string(1) "b"
    string(1) "c"

Actual result:
  0 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font> <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0000000bb00'>1</font>
  1 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font> <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0000000bb00'>2</font>
  2 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font>
      0 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font> <font
      1 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font> <font
      2 <font color='http://bugs.xdebug.org/bug_view_page.php?bug_id=0777777'>=&gt;</font> <font

 0x33 - 2004-11-24 15:43 CET
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

Frederic Poeydomenge

 derick - 2004-11-27 20:28 CET
As you said, not a bug, but a feature. Marking it as such.

Bug History
Date Modified Username Field Change
2004-11-20 19:110x33 New Bug
2004-11-24 15:350x33 Bug Monitored: 0x33
2004-11-24 15:350x33 Bug End Monitor: 0x33
2004-11-24 15:430x33 Bugnote Added: 0000214
2004-11-27 20:28derick Bugnote Added: 0000215
2004-11-27 20:28derick Assigned To => derick
2004-11-27 20:28derick Resolution open => not a bug
2004-11-27 20:28derick Status new => resolved
Received on Sat Nov 27 2004 - 20:28:46 GMT

This archive was generated by hypermail 2.2.0 : Sun Jun 24 2018 - 04:00:03 BST