php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #28012 spprintf() output inconsistent for %p (fix included)
Submitted: 2004-04-15 17:07 UTC Modified: 2004-04-15 19:18 UTC
From: php-lists at nomeaning dot net Assigned:
Status: Closed Package: Output Control
PHP Version: 5.0.0RC2RC1 OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2004-04-15 17:07 UTC] php-lists at nomeaning dot net 
Description:
------------
In all functions using spprintf(), the output corresponding to the format conversion specifier "%p" depends on the value of the *previous* argument (if any).

If the previously-converted argument was a non-zero integer, the string output will be prefixed with "0x", as intended.  

If the previously-converted argument was zero or a non-integer, the prefix will be missing.


Reproduce code:
---------------
I suspect you'll be able to clearly see this problem when examining the attached patch (fix), but I will attach a second patch which may be temporarily applied to php-src/ext/standard/var.c which causes php_var_dump to display the addresses of zval*s for the values displayed in a dump.

To reproduce the error, simply (in a PHP script) assign several numeric and non-numeric values to elements in an array, then use var_dump to display the contents of the array.


Expected result:
----------------
"0x" should prefix every pointer value, to indicate a hexadecimal address.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-04-15 17:15 UTC] php-lists at nomeaning dot net 
Hmmmm... no place to attach a patch, eh? Perhaps I'm blind or need full CVS access.  Well, it's short and sweet but I'll just post a link to the patches rather than pasting them in here.

http://www.nomeaning.net/temp/spprintf.tgz

The contents of the .tgz are:
1) The proposed fix, in spprintf.c.patch
2) The temporary patch to php_var_dump(), which you may or may not want to bother with, in var.c.patch.

It's clearly the most minor of minor bugs but the output of %p has puzzled me for a while and I decided today to track it down.  Hope this helps!
 [2004-04-15 17:23 UTC] php-lists at nomeaning dot net 
Having read README.SUBMITTING_PATCHES more carefully, I am emailing the patch to internals@lists.php.net.  Sorry for the confusion.
 [2004-04-15 19:08 UTC] helly@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 [2004-04-15 19:09 UTC] helly@php.net 
Thanks for noticing.

But printing the pointers through var.c is a nice thing for debugging but is a security risk for non debug mode.
 [2004-04-15 19:18 UTC] php-lists at nomeaning dot net 
Happy to help.

Re: The security risk.  I guess I failed to convey that my "patch" to var.c was merely to make reproducing the bug earlier for you.  By no means was I suggesting putting it in CVS!  (though the idea of printing pointers in var_dump() for --enable-debug mode is a good one)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 04:01:30 2024 UTC