INET_ADDR(3)

NAME
inet_aton, inet_addr, inet_network, inet_ntoa - Internet Protocol version 4 (IPv4) address manipulation routines

SYNOPSIS
#include <arpa/inet.h>
int
inet_aton(const char *cp, struct in_addr *addr);
in_addr_t
inet_addr(const char *cp);
in_addr_t
inet_network(const char *cp);
char *
inet_ntoa(struct in_addr in);

DESCRIPTION
The functions presented here only support IPv4 addresses. In order to support IPv6 addresses as well, inet_ntop(3) and inet_pton(3) should be used rather than the functions presented here. Scoped IPv6 addresses are supported via getaddrinfo(3) and getnameinfo(3).

The routines inet_aton(), inet_addr(), and inet_network() interpret character strings representing numbers expressed in the Internet standard “dot” notation.

The inet_aton() routine interprets the specified character string as an Internet address, placing the address into the structure provided. It returns 1 if the string was successfully interpreted, or 0 if the string was invalid.

The inet_addr() and inet_network() functions return numbers suitable for use as Internet addresses and Internet network numbers, respectively. Both functions return the constant INADDR_NONE if the specified character string is malformed.

The routine inet_ntoa() takes an Internet address and returns an ASCII string representing the address in dot notation.

All Internet addresses are returned in network order (bytes ordered from left to right). All network numbers and local address parts are returned as machine format integer values.

INTERNET ADDRESSES (IP VERSION 4)
Values specified using dot notation take one of the following forms:

    a.b.c.d
    a.b.c
    a.b
    a

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 Internet address. Note that when an Internet address is viewed as a 32-bit integer quantity on a system that uses little-endian byte order (such as the Intel 386, 486 and Pentium processors) the bytes referred to above appear as “d.c.b.a”. That is, little-endian bytes are ordered from right to left.

When a three part address is specified, the last part is interpreted as a 16-bit quantity and placed in the rightmost 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 rightmost 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.

All numbers supplied as “parts” in a dot notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0 implies octal; otherwise, the number is interpreted as decimal).

SEE ALSO
byteorder(3), gethostbyname(3), getnetent(3), inet_lnaof(3), inet_net(3), inet_ntop(3), hosts(5), networks(5)

STANDARDS
The inet_addr and inet_aton functions conform to p1003.1-2008.

HISTORY
The inet_addr and inet_network functions appeared in 4.2BSD. The inet_aton and inet_ntoa functions appeared in 4.3BSD.

BUGS
The value INADDR_NONE (0xffffffff) is a valid broadcast address, but inet_addr() cannot return that value without indicating failure. Also, inet_addr() should have been designed to return a struct in_addr. The newer inet_aton() function does not share these problems, and almost all existing code should be modified to use inet_aton() instead.

The problem of host byte ordering versus network byte ordering is confusing.

The string returned by inet_ntoa() resides in a static memory area.