SunOS man pages : inet (3)
Sockets Library Functions inet(3SOCKET)
NAME
inet, inet6, inet_ntop, inet_pton, inet_addr, inet_network,
inet_makeaddr, inet_lnaof, inet_netof, inet_ntoa - Internet
address manipulation
SYNOPSIS
cc [ flag ... ] file ... -lsocket -lnsl [ library ... ]
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
const char *inet_ntop(int af, const void *addr, char *cp,
size_t size);
int inet_pton(int af, const char *cp, void *addr);
in_addr_t inet_addr(const char *cp);
in_addr_t inet_network(const char *cp);
struct in_addr inet_makeaddr(const int net, const int lna);
int inet_lnaof(const struct in_addr in);
int inet_netof(const struct in_addr in);
char *inet_ntoa(const struct in_addr in);
DESCRIPTION
The inet_ntop() and inet_pton() routines can manipulate both
IPv4 and IPv6 addresses, whereas inet_addr(),
inet_network(), inet_makeaddr(), inet_lnaof(),
inet_netof(), and inet_ntoa() can only manipulate IPv4
addresses.
The inet_ntop() routine converts a numeric address into a
string suitable for presentation. The af argument specifies
the family of the address. This can be AF_INET or AF_INET6.
The addr argument points to a buffer holding an IPv4 address
if the af argument is AF_INET, or an IPv6 address if the af
argument is AF_INET6; the address must be in network byte
order. The cp argument points to a buffer where the routine
will store the resulting string. The size argument speci-
fies the size of this buffer. The application must specify
a non-NULL cp argument. For IPv6 addresses, the buffer must
be at least 46-octets. For IPv4 addresses, the buffer must
be at least 16-octets. In order to allow applications
to easily declare buffers of the proper size to store IPv4
and IPv6 addresses in string form, the following two con-
stants are defined in <netinet/in.h>:
SunOS 5.8 Last change: 3 Nov 1999 1
Sockets Library Functions inet(3SOCKET)
#define INET_ADDRSTRLEN 16
#define INET6_ADDRSTRLEN 46
The inet_pton() routine converts an address in its standard
text presentation form into its numeric binary form. The
af argument specifies the family of the address. Currently
the AF_INET and AF_INET6 address families are supported.
The cp argument points to the string being passed in.
The addr argument points to a buffer into which the routine
stores the numeric address. The calling application must
ensure that the buffer referred to by addr is large
enough to hold the numeric address, at least 4 bytes for
AF_INET or 16 bytes for AF_INET6.
The inet_addr() and inet_network() routines interpret char-
acter strings representing numbers expressed in the IPv4
standard `.' notation, returning numbers suitable for use as
IPv4 addresses and IPv4 network numbers, respectively. The
routine inet_makeaddr() takes an IPv4 network number and a
local network address and constructs an IPv4 address from
it. The routines inet_netof() and inet_lnaof() break apart
IPv4 host addresses, returning the network number and local
network address part, respectively.
The inet_ntoa() routine returns a pointer to a string in
the base 256 notation d.d.d.d. See INTERNET ADDRESSES.
Internet addresses are returned in network order, bytes
ordered from left to right. Network numbers and local
address parts are returned as machine format integer values.
INTERNET ADDRESSES
IPv6 Addresses
There are three conventional forms for representing IPv6
addresses
as strings:
1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are
the hexadecimal values of the eight 16-bit pieces of the
address, for example,
1080:0:0:0:8:800:200C:417A
Note that it is not necessary to write the leading zeros
in an individual field. However, there must be at least
one numeral in every field, except as described below.
2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain
long strings of zero bits. In order to make writing
addresses containing zero bits easier, a special syntax
SunOS 5.8 Last change: 3 Nov 1999 2
Sockets Library Functions inet(3SOCKET)
is available to compress the zeros. The use of "::" indi-
cates multiple groups of 16-bits of zeros. The "::" can
only appear once in an address. The "::" can also be
used to compress the leading and/or trailing zeros in an
address. For example,
1080::8:800:200C:417A
3. An alternative form that is sometimes more convenient
when dealing with a mixed environment of IPv4 and IPv6
nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hex-
adecimal values of the six high-order 16-bit pieces of
the address, and the 'd's are the decimal values of the
four low-order 8-bit pieces of the standard IPv4
representation address, for example,
::FFFF:129.144.52.38
::129.144.52.38
where "::FFFF:d.d.d.d" and "::d.d.d.d" are, respectively,
the general forms of an IPv4-mapped IPv6 address and an
IPv4-compatible IPv6 address. Note that the IPv4 portion
must be in the "d.d.d.d" form. The following forms are
invalid:
::FFFF:d.d.d
::FFFF:d.d
::d.d.d
::d.d
The following form:
::FFFF:d
is valid, however it is an unconventional representation
of the IPv4-compatible IPv6 address,
::255.255.0.d
while "::d" corresponds to the general IPv6 address
"0:0:0:0:0:0:0:d".
IPv4 Addresses
Values specified using `.' notation take one of the follow-
ing forms:
d.d.d.d
d.d.d
d.d
d
SunOS 5.8 Last change: 3 Nov 1999 3
Sockets Library Functions inet(3SOCKET)
When four parts are specified, each is interpreted as a byte
of data and assigned, from left to right, to the four bytes
of an IPv4 address.
When a three part address is specified, the last part is
interpreted as a 16-bit quantity and placed in the right
most two bytes of the network address. This makes the three
part address format convenient for specifying Class B net-
work addresses as 128.net.host.
When a two part address is supplied, the last part is inter-
preted as a 24-bit quantity and placed in the right most
three bytes of the network address. This makes the two part
address format convenient for specifying Class A network
addresses as net.host.
When only one part is given, the value is stored directly in
the network address without any byte rearrangement.
With the exception of inet_pton(), numbers supplied as
parts in `.' notation may be decimal, octal, or hexade-
cimal, as specified in the C language. For example, a lead-
ing 0x or 0X implies hexadecimal; otherwise, a leading 0
implies octal; otherwise, the number is interpreted as
decimal.
For IPv4 addresses, inet_pton() only accepts a string in the
standard IPv4 dotted-decimal form:
d.d.d.d
where each number has one to three digits with a decimal
value between 0 and 255.
RETURN VALUES
The inet_ntop() routine returns a pointer to the buffer con-
taining a string if the conversion succeeds, and NULL other-
wise. Upon failure, errno is set to EAFNOSUPPORT if the af
argument is invalid or ENOSPC if the size of the result
buffer is inadequate.
inet_pton() returns 1 if the conversion succeeds, 0 if the
input is not a valid IPv4 dotted-decimal string or a valid
IPv6 address string, or -1 with errno set to EAFNOSUPPORT
if the af argument is unknown.
The value -1 is returned by inet_addr() and inet_network()
for malformed requests.
The routines inet_netof() and inet_lnaof() break apart IPv4
host addresses, returning the network number and local
SunOS 5.8 Last change: 3 Nov 1999 4
Sockets Library Functions inet(3SOCKET)
network address part, respectively.
The routine inet_ntoa() returns a pointer to a string in the
base 256 notation d.d.d.d described in INTERNET ADDRESSES.
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| MT-Level | Safe |
|_____________________________|_____________________________|
SEE ALSO
gethostbyname(3NSL), getipnodebyname(3SOCKET),
getnetbyname(3SOCKET), inet(3HEAD), hosts(4), ipnodes(4),
networks(4), attributes(5)
NOTES
The return value from inet_ntoa() points to a buffer which
is overwritten on each call. This buffer is implemented as
thread-specific data in multithreaded applications.
BUGS
The problem of host byte ordering versus network byte order-
ing is confusing. A simple way to specify Class C network
addresses in a manner similar to that for Class B and Class
A is needed.
SunOS 5.8 Last change: 3 Nov 1999 5
|
 |
|
|
