OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [rtos/] [rtems/] [c/] [src/] [libnetworking/] [libc/] [inet.3] - Blame information for rev 507

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
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 .

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.