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, Ricky Beam wrote:

> 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.

I actually have, I'd just forgotten.

> 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.

No one's suggested anything of the sort. In C++, objects know how to print
themselves.

Anyway, in_ntoa is inherently bad - it returns a pointer to an internal
static buffer. Extending printk, a nonstandard _kernel debugging function_
to print IP addresses for kernel debugging is perfectly valid. The thing
that's imposing obnoxious type management is the compiler warnings.

> Instead of placing the burdon of programming on the compiler, leave it
> with the programmer.

So we should take printing of pointers and integers out of printk and
have only itoa-style functions? Bzzt.

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