No subject

Wed Aug 13 15:23:46 PDT 2008

Introduction, by Andrew M. Rudoff, Bill Fenner,=20
W. Richard Stevens:

"Today, inet_addr is deprecated and any new code should
use inet_aton instead. Better still is to use the newer
functions described in the next section, which handle
both IPv4 and IPv6."

and in that section we see:


Even if your system does not yet include support for IPv6,=20
you can start using these newer functions by replacing calls
of the form

foo.sin_addr.s_addr =3D inet_addr(cp);


inet_pton(AF_INET, cp, &foo.sin_addr);

and replacing calls of the form

ptr =3D inet_ntoa(foo.sin_addr);


ptr =3D inet_ntop(AF_INET, &foo.sin_addr, str, sizeof(str));


So what do we do with commonly-used interfaces that
have not yet been fully replaced in code in the field
by newer, more capable, and "preferred" interfaces? =20

I think it's pretty clear from this example what the
LSB selection philosophy has been in the past, where=20
we were aware of a conflict situation like this. We've
been informally advised to follow this approach by=20
upstreams, but it does leave situations where code may
have to be reworked before becoming LSB conforming,
or as in another case Robert has brought up, may cause
problems for code obtained from another vendor that
may not be available to modify.

-- mats

More information about the lsb-discuss mailing list