lkml.org 
[lkml]   [2000]   [Jul]   [6]   [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 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.050 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site