> However, it looks that ethereal tries to avoid use of AF_INET{,6}
> in the source code
Nope. Take a look at "resolv.c":
tooting$ egrep AF_INET resolv.c
hostp = gethostbyaddr((char *)&addr, 4, AF_INET);
hostp = gethostbyaddr((char *)addr, sizeof(*addr), AF_INET6);
> for portability (to be able to run on platforms
> that does not have AF_INET6),
We *do* avoid using it in "packet-null.c", but that's just because,
whilst the folks who implemented BPF for devices such as the loopback
device, in their, err, umm, infinite wisdom, decided to put BSD AF_
values into the fake packet header to indicate the protocol being used,
BSD AF_ values aren't necessarily the same on all platforms, so, in
order to be able to read a DLT_NULL capture file from a BSD system on an
OS with different AF_ values, we have to check for the *BSD* AF_INET and
AF_INET6 values.
Actually, it's even worse than that - there *isn't* a single BSD
AF_INET6 value! FreeBSD chose a *DIFFERENT* AF_INET6 value from other
BSDs, so we have to check for 24 (which is what OpenBSD chose, and, I
suspect, what NetBSD chose - did it?) and 28 (which is what FreeBSD
chose).
> and it prevents me from using standard inet_pton().
It's OK to use AF_INET and AF_INET6 as arguments to OS routines that use
them as arguments; just don't use them in "packet-null.c".
> What should I do in this case?
Go ahead and use "inet_pton()" (on platforms that have it, of course).
