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 Wed, 5 Jul 2000, Oliver Xymoron wrote:
>Wouldn't it be better to just teach vsprintf about addresses? This saves
>casting code all over the place. Then we have the much simpler:
>
> printk(KERN_DEBUG "foo: src=%a dst=%a\n", src, dst);

I gather you've not been around long enough to know this was already done
and abandoned due the the lack of compiler type checking for the new type.

Please, everyone, the kernel is written in C (and parts in native asm).
It's not C++, nor is it Java. Please don't try to impose their kinds of
data type management on C. Instead of placing the burdon of programming
on the compiler, leave it with the programmer. If you cannot write good
code without assistance of the compiler, please take some time to learn to
program. That being said, if you, the programmer, need to display two
human readable, text IP addresses in one printk(), then it's up to you,
the programmer, to create space to hold the two returned strings from
inet_ntoa -- which, I'll add, no longer exists in the current tree.

And incedentally, you _can_ call printk() twice:
printk(KERN_DEBUG "foo: src=%s", inet_ntoa(src));
printk(KERN_DEBUG " dst=%s\n", inet_ntoa(dst));

--Ricky

PS: I'll give both of you some points... at least you're thinking.



-
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.129 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site