printk adding unexpected padding '0' with ("%p")

[nashif]

Reported by Sharron LIU:

printk("%-2p", (void *)42);

expected:
0x2a

actual
0x0000002a

printf behaves as expected.
Is there any reason for printk to add prefix '0' when specifying format "%p"?

(Imported from Jira ZEP-2102)

[nashif]

by Andrew Boie:

I think this should be a P3, not a P2

[nashif]

by Sharron LIU:

Checked two related docs.

printf (libc) https://www.gnu.org/software/libc/manual/html_mono/libc.html#Other-Output-Conversions
This doc didn't tell explicitly whether padding '0' is required for "%p". However, when explaining '0' padding conversion, it says

‘0’
    Pad the field with zeros instead of spaces; the zeros are placed after any sign. This flag is ignored if the ‘-’ flag is also specified.

printk (kernel) https://www.kernel.org/doc/Documentation/printk-formats.txt
This doc didn't tell either, whether padding '0' is required when printing a raw pointer "%p".
However, it described a lot of "extended format specifiers for pointer types". Among those, some with padding '0', others not.

%pF	versatile_init+0x0/0x110                                         >> function pointer, no padding '0'
%pK	0x01234567 or 0x0123456789abcdef                    >> kernel pointer, padding '0'
%pad	0x01234567 or 0x0123456789abcde             >> DMA addr pointer, padding '0'

Zephyr printk probably behaves similar to the linux kernel printk, with padding '0'.

[nashif]

by Leandro Pereira:

A pointer is always 4-bytes long in Zephyr, so it makes sense, to me, to always ignore the precision when printing it out with printk(). It seems that whoever wrote the printk() in Linux agrees with this as well.

If you need to print a pointer that is known to have just two nibbles, convert it to an uintptr_t and use %x instead: printk() is supposed to be tiny, and adding cases that are rare as this will increase the code size for absolutely no need.

[nashif]

Related to GH-1460