|
Sockets Library Functions | inet(3SOCKET) |
| 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); |
|
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 specifies 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 constants are defined in <netinet/in.h>:
|
#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 character 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.
|
|
IPv6 Addresses
|
There are three conventional forms for representing IPv6 addresses
as strings:
- 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.
- 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 is available to compress the zeros. The use of
"::" indicates 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,
- 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
hexadecimal 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: is
valid, however it is an unconventional representation of the IPv4-compatible
IPv6 address,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 following forms: 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 network addresses as 128.net.host.
When a two part address is supplied, the last part is interpreted
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 hexadecimal, as specified in the C language. For
example, a leading 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: where each number has one to three digits with a decimal
value between 0 and 255.
|
|
|
The inet_ntop() routine returns a pointer to the
buffer containing a string if the conversion succeeds, and NULL otherwise. 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 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.
|
|
See attributes(5)
for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
MT-Level | Safe |
|
|
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.
|
|
The problem of host byte ordering versus network byte ordering 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.
|
| |