On 22/09/2022 18:19, Beata Michalska wrote:
- %#lp[x] 0123456789abcdef[rwxRWE,0000000000000000,ffffffffffffffff]
Space before "[", and "-" between the bounds instead of "," to match the format below.
Additionally, to match [1], all values should be preceded by "0x".
So that would actually contradict to how pointers/addresses are being currently printed where the '0x' prefix is not added unless explicitly requested. But then the '#' flag used for that purpose is already being overloaded to switch to simplified format. Note also that [1] does mention being compliant with existing formats. I could use the prefix for the simplified format only, but that one can cause some confusion. No strong opinion here.
AFAICT there is no significant divergence in printk() w.r.t. 0x: just like in standard printf(), you don't get 0x unless you ask for the "alternate format" with the # flag. You could certainly argue with the choice of using the # flag to ask for the simplified format too, but since we're using that too I'd just go for the same format as [1]. I might be missing something about how printk() handles things though.
In theory the '#' flag for "%p" format is undefined result (and that's for printf which will trigger a warning on that one: warning: '#' flag used with ‘%p’ gnu_printf format [-Wformat=] ). Kernel's printk will allow that but that's probably not really intended. Plain pointers (with plain "%p") are being printed without the prefix. Now with capability printing, the '#' flags gets somehow legitimate, so I guess for this particular case we could play along with [1] and add the prefix for simplified format. Which might actually make sense while looking at other printk extensions to '%p' format.
I had missed the fact that printk diverges from printf when it comes to "%p": printk prints it as "%lx" while printf prints it as "%#lx". As a result I think there are good arguments for both using and not using 0x in "%#lp" and I really don't mind either way.
Kevin