# [PATCH] fix for inconsistent output of spprintf() (for %p specifier)

- Thread: https://externals.io/message/9236
- Original archive: https://news-web.php.net/php.internals/9236
- Started by Eric Lambart on 2004-04-15T21:30:07+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #9236 — Eric Lambart — 2004-04-15T21:30:07+00:00

URL: https://externals.io/message/9236#9236

Hello folks,
In all functions using spprintf(), the output corresponding to the
format conversion specifier "%p" depends on the value of the
*previously* converted argument (if any), not just the pointer
corresponding to the specifier.

1) If the previously-converted argument was a non-zero integer, the
hexadecimal string value will be correctly prefixed with "0x".
2) If there was no previously-converted argument, or if it was zero or a
non-integer, the "0x" hexadecimal prefix will be missing.

The attached patch fixes this problem, as also reported in bug #28012
http://bugs.php.net/bug.php?id=28012

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!

Thanks,
Eric Lambart

---

## #9243 — Marcus Boerger — 2004-04-15T23:11:55+00:00

URL: https://externals.io/message/9236#9243 · In reply to: #9236

Hello Eric,

thanks for noticing.

marcus

Thursday, April 15, 2004, 11:30:07 PM, you wrote:

> Hello folks,
> In all functions using spprintf(), the output corresponding to the
> format conversion specifier "%p" depends on the value of the
> *previously* converted argument (if any), not just the pointer
> corresponding to the specifier.

[...]