php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php-lists at nomeaning dot net
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2025 The PHP Group
All rights reserved.
Last updated: Thu May 01 20:01:29 2025 UTC