Messages in this thread | | | Date | Wed, 5 Jul 2000 19:39:02 -0400 (EDT) | From | Ricky Beam <> | Subject | Re: [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/
| |