lkml.org 
[lkml]   [2000]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] solution for the inet_ntoa problem, buffer allocator
On Thu, 6 Jul 2000, Andrew Morton wrote:

> > printk(KERN_DEBUG "foo: src=%a dst=%a\n", src, dst);
>
> Problem with this is that `gcc -Wall' will generate a warning when it
> checks the format string.

Ahh, forgot about that..

> I proposed a little hack which avoided that a while back, but it got
> loudly ignored at.
>
> #define FMT_IP4 "\001%ld"
>
> printk(KERN_DEBUG "foo: src=" FMT_IP4 " dst= " FMT_IP4 "\n", src, dst);

Yuck! If we're gonna be hackish, we can use the # flag on d or something:

printk(KERN_DEBUG "foo: src=%#d dst=%#d\n", &src, &dst);

Though gcc apparently thinks this is a warnable offense as well. #$#$.

If you were going to do something like the ctrl-a hack, I'd propose using
an easily-typed control character as an alternate '%':

printk(KERN_DEBUG "foo: src=\vi dst=\vi \n", src, dst);

\v is ASCII 11, not used for much of anything and hopefully not appearing
in any existing format strings. You now have a whole alphabet of new
format characters.

Of course, this undoes the benefit of the format checking, but when
compared to hacks like putting dynamic allocation in in_ntoa..

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.053 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site