Messages in this thread | | | Date | Wed, 5 Jul 2000 22:41:16 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: [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/
| |