Signed-off-by: Al Viro <[email protected]>
---
drivers/sbus/char/uctrl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/sbus/char/uctrl.c b/drivers/sbus/char/uctrl.c
index ddc0681..b30372f 100644
--- a/drivers/sbus/char/uctrl.c
+++ b/drivers/sbus/char/uctrl.c
@@ -400,7 +400,7 @@ static int __init ts102_uctrl_init(void)
}
driver->regs->uctrl_intr = UCTRL_INTR_RXNE_REQ|UCTRL_INTR_RXNE_MSK;
- printk("uctrl: 0x%x (irq %d)\n", driver->regs, driver->irq);
+ printk("uctrl: 0x%p (irq %d)\n", driver->regs, driver->irq);
uctrl_get_event_status();
uctrl_get_external_status();
return 0;
--
1.4.2.GIT
From: Al Viro <[email protected]>
Date: Tue, 10 Oct 2006 22:49:57 +0100
>
> Signed-off-by: Al Viro <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
>diff --git a/drivers/sbus/char/uctrl.c b/drivers/sbus/char/uctrl.c
>index ddc0681..b30372f 100644
>--- a/drivers/sbus/char/uctrl.c
>+++ b/drivers/sbus/char/uctrl.c
>@@ -400,7 +400,7 @@ static int __init ts102_uctrl_init(void)
> }
>
> driver->regs->uctrl_intr = UCTRL_INTR_RXNE_REQ|UCTRL_INTR_RXNE_MSK;
>- printk("uctrl: 0x%x (irq %d)\n", driver->regs, driver->irq);
>+ printk("uctrl: 0x%p (irq %d)\n", driver->regs, driver->irq);
So what's the difference, except that %p will evaluate to (nil) or
(null) when the argument is 0 [this is the case with glibc]?
That would print 0x(nil).
-`J'
--
On Wed, Oct 11, 2006 at 01:16:56PM +0200, Jan Engelhardt wrote:
>
> >diff --git a/drivers/sbus/char/uctrl.c b/drivers/sbus/char/uctrl.c
> >index ddc0681..b30372f 100644
> >--- a/drivers/sbus/char/uctrl.c
> >+++ b/drivers/sbus/char/uctrl.c
> >@@ -400,7 +400,7 @@ static int __init ts102_uctrl_init(void)
> > }
> >
> > driver->regs->uctrl_intr = UCTRL_INTR_RXNE_REQ|UCTRL_INTR_RXNE_MSK;
> >- printk("uctrl: 0x%x (irq %d)\n", driver->regs, driver->irq);
> >+ printk("uctrl: 0x%p (irq %d)\n", driver->regs, driver->irq);
>
> So what's the difference, except that %p will evaluate to (nil) or
> (null) when the argument is 0 [this is the case with glibc]?
> That would print 0x(nil).
%p will do no such thing in the kernel. As for the difference... %x
might happen to work on some architectures (where sizeof(void *)==sizeof(int)),
but it's not portable _and_ not right. %p is proper C for that...
Al Viro wrote:
>
> %p will do no such thing in the kernel. As for the difference... %x
> might happen to work on some architectures (where sizeof(void *)==sizeof(int)),
> but it's not portable _and_ not right. %p is proper C for that...
It's really too bad gcc bitches about %#p, because that's arguably The
Right Thing.
-hpa
>> %p will do no such thing in the kernel. As for the difference... %x
>> might happen to work on some architectures (where sizeof(void
>> *)==sizeof(int)),
>> but it's not portable _and_ not right. %p is proper C for that...
Ah I see your point, but then again, %lx could have been used. Unless
there is some arch where sizeof(long) != sizeof(void *).
> It's really too bad gcc bitches about %#p, because that's arguably The Right
> Thing.
ack. Make a bug report perhaps?
-`J'
--
Jan Engelhardt wrote:
>>> %p will do no such thing in the kernel. As for the difference... %x
>>> might happen to work on some architectures (where sizeof(void
>>> *)==sizeof(int)),
>>> but it's not portable _and_ not right. %p is proper C for that...
>
> Ah I see your point, but then again, %lx could have been used. Unless
> there is some arch where sizeof(long) != sizeof(void *).
That really makes gcc bitch, *and* it's wrong for a whole bunch of reasons.
>> It's really too bad gcc bitches about %#p, because that's arguably The Right
>> Thing.
>
> ack. Make a bug report perhaps?
Maybe. They'll probably say "the C standard says so" :-/
-hpa
>> > > %p will do no such thing in the kernel. As for the difference...
>> > > %x
>> > > might happen to work on some architectures (where sizeof(void
>> > > *)==sizeof(int)),
>> > > but it's not portable _and_ not right. %p is proper C for that...
>>
>> Ah I see your point, but then again, %lx could have been used. Unless
>> there is some arch where sizeof(long) != sizeof(void *).
>
> That really makes gcc bitch, *and* it's wrong for a whole bunch of reasons.
Ah my bad. Thanks for the slap reminder. :)
-`J'
--
On Wed, Oct 11, 2006 at 11:45:10AM -0700, H. Peter Anvin wrote:
> Al Viro wrote:
> >
> >%p will do no such thing in the kernel. As for the difference... %x
> >might happen to work on some architectures (where sizeof(void
> >*)==sizeof(int)),
> >but it's not portable _and_ not right. %p is proper C for that...
>
> It's really too bad gcc bitches about %#p, because that's arguably The
> Right Thing.
It is correct that gcc warns about %#p, that invokes undefined behavior
in ISO C99.
Jakub
Jakub Jelinek wrote:
> On Wed, Oct 11, 2006 at 11:45:10AM -0700, H. Peter Anvin wrote:
>> Al Viro wrote:
>>> %p will do no such thing in the kernel. As for the difference... %x
>>> might happen to work on some architectures (where sizeof(void
>>> *)==sizeof(int)),
>>> but it's not portable _and_ not right. %p is proper C for that...
>> It's really too bad gcc bitches about %#p, because that's arguably The
>> Right Thing.
>
> It is correct that gcc warns about %#p, that invokes undefined behavior
> in ISO C99.
>
Yes, it's a bug in the standard.
-hpa
H. Peter Anvin writes:
> Al Viro wrote:
> >
> > %p will do no such thing in the kernel. As for the difference... %x
> > might happen to work on some architectures (where sizeof(void *)==sizeof(int)),
> > but it's not portable _and_ not right. %p is proper C for that...
>
> It's really too bad gcc bitches about %#p, because that's arguably The
> Right Thing.
Hm...
man 3 printf:
p The void * pointer argument is printed in hexadeci-
mal (as if by %#x or %#lx).
so %p already has to output '0x', it's lib/vsprintf.c to blame for
non-conforming behavior. What about
Signed-off-by: Nikita Danilov <[email protected]>
Index: git-linux/lib/vsprintf.c
===================================================================
--- git-linux.orig/lib/vsprintf.c
+++ git-linux/lib/vsprintf.c
@@ -408,7 +408,7 @@ int vsnprintf(char *buf, size_t size, co
}
str = number(str, end,
(unsigned long) va_arg(args, void *),
- 16, field_width, precision, flags);
+ 16, field_width, precision, flags|SPECIAL);
continue;
Nikita Danilov <[email protected]> writes:
> man 3 printf:
>
> p The void * pointer argument is printed in hexadeci-
> mal (as if by %#x or %#lx).
>
> so %p already has to output '0x',
That is an detail of this particular implementation.
> it's lib/vsprintf.c to blame for non-conforming behavior.
The standard makes it completely implementation defined.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Andreas Schwab writes:
> Nikita Danilov <[email protected]> writes:
>
> > man 3 printf:
> >
> > p The void * pointer argument is printed in hexadeci-
> > mal (as if by %#x or %#lx).
> >
> > so %p already has to output '0x',
>
> That is an detail of this particular implementation.
>
> > it's lib/vsprintf.c to blame for non-conforming behavior.
>
> The standard makes it completely implementation defined.
Yes, but POSIX/SUS aside, at least we might make kernel version closer
to Linux user-level.
>
> Andreas.
Nikita.
> > > man 3 printf:
> > >
> > > p The void * pointer argument is printed in hexadeci-
> > > mal (as if by %#x or %#lx).
> > >
> > > so %p already has to output '0x',
> >
> > That is an detail of this particular implementation.
> >
> > > it's lib/vsprintf.c to blame for non-conforming behavior.
> >
> > The standard makes it completely implementation defined.
>
>Yes, but POSIX/SUS aside, at least we might make kernel version closer
>to Linux user-level.
I do agree.
#include <stdio.h>
int main(void) {
return printf("%p %p\n", main, NULL);
}
In glibc will print "0x7555562c (nil)" which seems ok enough.
-`J'
--
>so %p already has to output '0x', it's lib/vsprintf.c to blame for
>non-conforming behavior. What about
>
>Signed-off-by: Nikita Danilov <[email protected]>
>
>Index: git-linux/lib/vsprintf.c
Seems like the mail I wrote did not arrive. In that case, I'll give you
an URL: http://jengelh.hopto.org/f/nikita-printf-p.diff.bz2 (compile
tested)
Signed-off-by: Jan Engelhardt <[email protected]>
-`J'
--