Messages in this thread | | | Date | Thu, 6 Jul 2000 00:10:23 -0500 (CDT) | From | Oliver Xymoron <> | Subject | Re: [RFC] solution for the inet_ntoa problem, buffer allocator |
| |
On Thu, 6 Jul 2000, Lincoln Dale wrote:
> At 23:41 05/07/00, Oliver Xymoron wrote: > > > > 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. > > i've long-since used something like this: > > #define inet_int_ntoa(addr) \ > (addr) & 0xff, \ > (addr>>8) & 0xff, \ > (addr>>16) & 0xff, \ > (addr>>24) & 0xff
There's NIPQUAD in the kernel, which pretty much does the same thing. Your above version has an endianness problem though - all addresses are in network order and you assume machine order. Macros that expand quietly expand into four args are a bit too magic for my taste, but it's arguably less magic than in_ntoa since the compiler will probably notice when you use it wrong.
-- "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/
| |