1 |
30 |
unneback |
.\" Copyright (c) 1983, 1990, 1991, 1993
|
2 |
|
|
.\" The Regents of the University of California. All rights reserved.
|
3 |
|
|
.\"
|
4 |
|
|
.\" Redistribution and use in source and binary forms, with or without
|
5 |
|
|
.\" modification, are permitted provided that the following conditions
|
6 |
|
|
.\" are met:
|
7 |
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
8 |
|
|
.\" notice, this list of conditions and the following disclaimer.
|
9 |
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
10 |
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
11 |
|
|
.\" documentation and/or other materials provided with the distribution.
|
12 |
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
13 |
|
|
.\" must display the following acknowledgement:
|
14 |
|
|
.\" This product includes software developed by the University of
|
15 |
|
|
.\" California, Berkeley and its contributors.
|
16 |
|
|
.\" 4. Neither the name of the University nor the names of its contributors
|
17 |
|
|
.\" may be used to endorse or promote products derived from this software
|
18 |
|
|
.\" without specific prior written permission.
|
19 |
|
|
.\"
|
20 |
|
|
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
21 |
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
22 |
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
23 |
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
24 |
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
25 |
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
26 |
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
27 |
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
28 |
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
29 |
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
30 |
|
|
.\" SUCH DAMAGE.
|
31 |
|
|
.\"
|
32 |
|
|
.\" From: @(#)inet.3 8.1 (Berkeley) 6/4/93
|
33 |
|
|
.\" $Id: inet.3,v 1.2 2001-09-27 12:01:53 chris Exp $
|
34 |
|
|
.\"
|
35 |
|
|
.Dd June 17, 1996
|
36 |
|
|
.Dt INET 3
|
37 |
|
|
.Os BSD 4.2
|
38 |
|
|
.Sh NAME
|
39 |
|
|
.Nm inet_aton ,
|
40 |
|
|
.Nm inet_addr ,
|
41 |
|
|
.Nm inet_network ,
|
42 |
|
|
.Nm inet_ntoa ,
|
43 |
|
|
.Nm inet_makeaddr ,
|
44 |
|
|
.Nm inet_lnaof ,
|
45 |
|
|
.Nm inet_netof
|
46 |
|
|
.Nd Internet address manipulation routines
|
47 |
|
|
.Sh SYNOPSIS
|
48 |
|
|
.Fd #include
|
49 |
|
|
.Fd #include
|
50 |
|
|
.Fd #include
|
51 |
|
|
.Fd #include
|
52 |
|
|
.Ft int
|
53 |
|
|
.Fn inet_aton "const char *cp" "struct in_addr *pin"
|
54 |
|
|
.Ft unsigned long
|
55 |
|
|
.Fn inet_addr "const char *cp"
|
56 |
|
|
.Ft unsigned long
|
57 |
|
|
.Fn inet_network "const char *cp"
|
58 |
|
|
.Ft char *
|
59 |
|
|
.Fn inet_ntoa "struct in_addr in"
|
60 |
|
|
.Ft struct in_addr
|
61 |
|
|
.Fn inet_makeaddr "unsigned long net" "unsigned long lna"
|
62 |
|
|
.Ft unsigned long
|
63 |
|
|
.Fn inet_lnaof "struct in_addr in"
|
64 |
|
|
.Ft unsigned long
|
65 |
|
|
.Fn inet_netof "struct in_addr in"
|
66 |
|
|
.Sh DESCRIPTION
|
67 |
|
|
The routines
|
68 |
|
|
.Fn inet_aton ,
|
69 |
|
|
.Fn inet_addr
|
70 |
|
|
and
|
71 |
|
|
.Fn inet_network
|
72 |
|
|
interpret character strings representing
|
73 |
|
|
numbers expressed in the Internet standard
|
74 |
|
|
.Ql \&.
|
75 |
|
|
notation.
|
76 |
|
|
The
|
77 |
|
|
.Fn inet_aton
|
78 |
|
|
routine interprets the specified character string as an Internet address,
|
79 |
|
|
placing the address into the structure provided.
|
80 |
|
|
It returns 1 if the string was successfully interpreted,
|
81 |
|
|
or 0 if the string is invalid.
|
82 |
|
|
The
|
83 |
|
|
.Fn inet_addr
|
84 |
|
|
and
|
85 |
|
|
.Fn inet_network
|
86 |
|
|
functions return numbers suitable for use
|
87 |
|
|
as Internet addresses and Internet network
|
88 |
|
|
numbers, respectively.
|
89 |
|
|
The routine
|
90 |
|
|
.Fn inet_ntoa
|
91 |
|
|
takes an Internet address and returns an
|
92 |
|
|
.Tn ASCII
|
93 |
|
|
string representing the address in
|
94 |
|
|
.Ql \&.
|
95 |
|
|
notation. The routine
|
96 |
|
|
.Fn inet_makeaddr
|
97 |
|
|
takes an Internet network number and a local
|
98 |
|
|
network address and constructs an Internet address
|
99 |
|
|
from it. The routines
|
100 |
|
|
.Fn inet_netof
|
101 |
|
|
and
|
102 |
|
|
.Fn inet_lnaof
|
103 |
|
|
break apart Internet host addresses, returning
|
104 |
|
|
the network number and local network address part,
|
105 |
|
|
respectively.
|
106 |
|
|
.Pp
|
107 |
|
|
All Internet addresses are returned in network
|
108 |
|
|
order (bytes ordered from left to right).
|
109 |
|
|
All network numbers and local address parts are
|
110 |
|
|
returned as machine format integer values.
|
111 |
|
|
.Sh INTERNET ADDRESSES
|
112 |
|
|
Values specified using the
|
113 |
|
|
.Ql \&.
|
114 |
|
|
notation take one
|
115 |
|
|
of the following forms:
|
116 |
|
|
.Bd -literal -offset indent
|
117 |
|
|
a.b.c.d
|
118 |
|
|
a.b.c
|
119 |
|
|
a.b
|
120 |
|
|
a
|
121 |
|
|
.Ed
|
122 |
|
|
.Pp
|
123 |
|
|
When four parts are specified, each is interpreted
|
124 |
|
|
as a byte of data and assigned, from left to right,
|
125 |
|
|
to the four bytes of an Internet address. Note
|
126 |
|
|
that when an Internet address is viewed as a 32-bit
|
127 |
|
|
integer quantity on the
|
128 |
|
|
.Tn VAX
|
129 |
|
|
the bytes referred to
|
130 |
|
|
above appear as
|
131 |
|
|
.Dq Li d.c.b.a .
|
132 |
|
|
That is,
|
133 |
|
|
.Tn VAX
|
134 |
|
|
bytes are
|
135 |
|
|
ordered from right to left.
|
136 |
|
|
.Pp
|
137 |
|
|
When a three part address is specified, the last
|
138 |
|
|
part is interpreted as a 16-bit quantity and placed
|
139 |
|
|
in the right-most two bytes of the network address.
|
140 |
|
|
This makes the three part address format convenient
|
141 |
|
|
for specifying Class B network addresses as
|
142 |
|
|
.Dq Li 128.net.host .
|
143 |
|
|
.Pp
|
144 |
|
|
When a two part address is supplied, the last part
|
145 |
|
|
is interpreted as a 24-bit quantity and placed in
|
146 |
|
|
the right most three bytes of the network address.
|
147 |
|
|
This makes the two part address format convenient
|
148 |
|
|
for specifying Class A network addresses as
|
149 |
|
|
.Dq Li net.host .
|
150 |
|
|
.Pp
|
151 |
|
|
When only one part is given, the value is stored
|
152 |
|
|
directly in the network address without any byte
|
153 |
|
|
rearrangement.
|
154 |
|
|
.Pp
|
155 |
|
|
All numbers supplied as
|
156 |
|
|
.Dq parts
|
157 |
|
|
in a
|
158 |
|
|
.Ql \&.
|
159 |
|
|
notation
|
160 |
|
|
may be decimal, octal, or hexadecimal, as specified
|
161 |
|
|
in the C language (i.e., a leading 0x or 0X implies
|
162 |
|
|
hexadecimal; otherwise, a leading 0 implies octal;
|
163 |
|
|
otherwise, the number is interpreted as decimal).
|
164 |
|
|
.Pp
|
165 |
|
|
The
|
166 |
|
|
.Fn inet_aton
|
167 |
|
|
and
|
168 |
|
|
.Fn inet_ntoa
|
169 |
|
|
functions are semi-deprecated in favor of the
|
170 |
|
|
.Xr addr2ascii 3
|
171 |
|
|
family. However, since those functions are not yet widely implemented,
|
172 |
|
|
portable programs cannot rely on their presence and will continue
|
173 |
|
|
to use the
|
174 |
|
|
.Xr inet 3
|
175 |
|
|
functions for some time.
|
176 |
|
|
.Sh DIAGNOSTICS
|
177 |
|
|
The constant
|
178 |
|
|
.Dv INADDR_NONE
|
179 |
|
|
is returned by
|
180 |
|
|
.Fn inet_addr
|
181 |
|
|
and
|
182 |
|
|
.Fn inet_network
|
183 |
|
|
for malformed requests.
|
184 |
|
|
.Sh SEE ALSO
|
185 |
|
|
.Xr addr2ascii 3 ,
|
186 |
|
|
.Xr gethostbyname 3 ,
|
187 |
|
|
.Xr getnetent 3 ,
|
188 |
|
|
.Xr hosts 5 ,
|
189 |
|
|
.Xr networks 5
|
190 |
|
|
.Sh HISTORY
|
191 |
|
|
These
|
192 |
|
|
functions appeared in
|
193 |
|
|
.Bx 4.2 .
|
194 |
|
|
.Sh BUGS
|
195 |
|
|
The value
|
196 |
|
|
.Dv INADDR_NONE
|
197 |
|
|
(0xffffffff) is a valid broadcast address, but
|
198 |
|
|
.Fn inet_addr
|
199 |
|
|
cannot return that value without indicating failure.
|
200 |
|
|
The newer
|
201 |
|
|
.Fn inet_aton
|
202 |
|
|
function does not share this problem.
|
203 |
|
|
The problem of host byte ordering versus network byte ordering is
|
204 |
|
|
confusing.
|
205 |
|
|
The string returned by
|
206 |
|
|
.Fn inet_ntoa
|
207 |
|
|
resides in a static memory area.
|
208 |
|
|
.Pp
|
209 |
|
|
Inet_addr should return a
|
210 |
|
|
.Fa struct in_addr .
|