[xdebug-dev] Bug 0000105: Fancy var_dump function vs Var_Dump class from xdebug-dev[@]lists.xdebug.org on 2004-11-27 (Xdebug Development List)

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

The following bug has been RESOLVED.
======================================================================
http://bugs.xdebug.org/bug_view_page.php?bug_id=0000105
======================================================================
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
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>
array
 0 => 1
 1 => 2
 2 =>
 array
 0 => 'a'
 1 => 'b'
 2 => 'c'
</pre>
======================================================================

----------------------------------------------------------------------
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
bogus.

Regards
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