1 |
578 |
markom |
'\"
|
2 |
|
|
'\" Copyright (c) 1997 by Sun Microsystems, Inc.
|
3 |
|
|
'\"
|
4 |
|
|
'\" See the file "license.terms" for information on usage and redistribution
|
5 |
|
|
'\" of this file, and for a DISCLAIMER OF ALL WARRANTIES.
|
6 |
|
|
'\"
|
7 |
|
|
'\" RCS: @(#) $Id: binary.n,v 1.1.1.1 2002-01-16 10:25:24 markom Exp $
|
8 |
|
|
'\"
|
9 |
|
|
.so man.macros
|
10 |
|
|
.TH binary n 8.0 Tcl "Tcl Built-In Commands"
|
11 |
|
|
.BS
|
12 |
|
|
'\" Note: do not modify the .SH NAME line immediately below!
|
13 |
|
|
.SH NAME
|
14 |
|
|
binary \- Insert and extract fields from binary strings
|
15 |
|
|
.SH SYNOPSIS
|
16 |
|
|
\fBbinary format \fIformatString \fR?\fIarg arg ...\fR?
|
17 |
|
|
.br
|
18 |
|
|
\fBbinary scan \fIstring formatString \fR?\fIvarName varName ...\fR?
|
19 |
|
|
.BE
|
20 |
|
|
|
21 |
|
|
.SH DESCRIPTION
|
22 |
|
|
.PP
|
23 |
|
|
This command provides facilities for manipulating binary data. The
|
24 |
|
|
first form, \fBbinary format\fR, creates a binary string from normal
|
25 |
|
|
Tcl values. For example, given the values 16 and 22, it might produce
|
26 |
|
|
an 8-byte binary string consisting of two 4-byte integers, one for
|
27 |
|
|
each of the numbers. The second form of the command,
|
28 |
|
|
\fBbinary scan\fR, does the opposite: it extracts data from a binary
|
29 |
|
|
string and returns it as ordinary Tcl string values.
|
30 |
|
|
|
31 |
|
|
.SH "BINARY FORMAT"
|
32 |
|
|
.PP
|
33 |
|
|
The \fBbinary format\fR command generates a binary string whose layout
|
34 |
|
|
is specified by the \fIformatString\fR and whose contents come from
|
35 |
|
|
the additional arguments. The resulting binary value is returned.
|
36 |
|
|
.PP
|
37 |
|
|
The \fIformatString\fR consists of a sequence of zero or more field
|
38 |
|
|
specifiers separated by zero or more spaces. Each field specifier is
|
39 |
|
|
a single type character followed by an optional numeric \fIcount\fR.
|
40 |
|
|
Most field specifiers consume one argument to obtain the value to be
|
41 |
|
|
formatted. The type character specifies how the value is to be
|
42 |
|
|
formatted. The \fIcount\fR typically indicates how many items of the
|
43 |
|
|
specified type are taken from the value. If present, the \fIcount\fR
|
44 |
|
|
is a non-negative decimal integer or \fB*\fR, which normally indicates
|
45 |
|
|
that all of the items in the value are to be used. If the number of
|
46 |
|
|
arguments does not match the number of fields in the format string
|
47 |
|
|
that consume arguments, then an error is generated.
|
48 |
|
|
.PP
|
49 |
|
|
Each type-count pair moves an imaginary cursor through the binary
|
50 |
|
|
data, storing bytes at the current position and advancing the cursor
|
51 |
|
|
to just after the last byte stored. The cursor is initially at
|
52 |
|
|
position 0 at the beginning of the data. The type may be any one of
|
53 |
|
|
the following characters:
|
54 |
|
|
.IP \fBa\fR 5
|
55 |
|
|
Stores a character string of length \fIcount\fR in the output string.
|
56 |
|
|
If \fIarg\fR has fewer than \fIcount\fR bytes, then additional zero
|
57 |
|
|
bytes are used to pad out the field. If \fIarg\fR is longer than the
|
58 |
|
|
specified length, the extra characters will be ignored. If
|
59 |
|
|
\fIcount\fR is \fB*\fR, then all of the bytes in \fIarg\fR will be
|
60 |
|
|
formatted. If \fIcount\fR is omitted, then one character will be
|
61 |
|
|
formatted. For example,
|
62 |
|
|
.RS
|
63 |
|
|
.CS
|
64 |
|
|
\fBbinary format a7a*a alpha bravo charlie\fR
|
65 |
|
|
.CE
|
66 |
|
|
will return a string equivalent to \fBalpha\\000\\000bravoc\fR.
|
67 |
|
|
.RE
|
68 |
|
|
.IP \fBA\fR 5
|
69 |
|
|
This form is the same as \fBa\fR except that spaces are used for
|
70 |
|
|
padding instead of nulls. For example,
|
71 |
|
|
.RS
|
72 |
|
|
.CS
|
73 |
|
|
\fBbinary format A6A*A alpha bravo charlie\fR
|
74 |
|
|
.CE
|
75 |
|
|
will return \fBalpha bravoc\fR.
|
76 |
|
|
.RE
|
77 |
|
|
.IP \fBb\fR 5
|
78 |
|
|
Stores a string of \fIcount\fR binary digits in low-to-high order
|
79 |
|
|
within each byte in the output string. \fIArg\fR must contain a
|
80 |
|
|
sequence of \fB1\fR and \fB0\fR characters. The resulting bytes are
|
81 |
|
|
emitted in first to last order with the bits being formatted in
|
82 |
|
|
low-to-high order within each byte. If \fIarg\fR has fewer than
|
83 |
|
|
\fIcount\fR digits, then zeros will be used for the remaining bits.
|
84 |
|
|
If \fIarg\fR has more than the specified number of digits, the extra
|
85 |
|
|
digits will be ignored. If \fIcount\fR is \fB*\fR, then all of the
|
86 |
|
|
digits in \fIarg\fR will be formatted. If \fIcount\fR is omitted,
|
87 |
|
|
then one digit will be formatted. If the number of bits formatted
|
88 |
|
|
does not end at a byte boundary, the remaining bits of the last byte
|
89 |
|
|
will be zeros. For example,
|
90 |
|
|
.RS
|
91 |
|
|
.CS
|
92 |
|
|
\fBbinary format b5b* 11100 111000011010\fR
|
93 |
|
|
.CE
|
94 |
|
|
will return a string equivalent to \fB\\x07\\x87\\x05\fR.
|
95 |
|
|
.RE
|
96 |
|
|
.IP \fBB\fR 5
|
97 |
|
|
This form is the same as \fBb\fR except that the bits are stored in
|
98 |
|
|
high-to-low order within each byte. For example,
|
99 |
|
|
.RS
|
100 |
|
|
.CS
|
101 |
|
|
\fBbinary format B5B* 11100 111000011010\fR
|
102 |
|
|
.CE
|
103 |
|
|
will return a string equivalent to \fB\\xe0\\xe1\\xa0\fR.
|
104 |
|
|
.RE
|
105 |
|
|
.IP \fBh\fR 5
|
106 |
|
|
Stores a string of \fIcount\fR hexadecimal digits in low-to-high
|
107 |
|
|
within each byte in the output string. \fIArg\fR must contain a
|
108 |
|
|
sequence of characters in the set ``0123456789abcdefABCDEF''. The
|
109 |
|
|
resulting bytes are emitted in first to last order with the hex digits
|
110 |
|
|
being formatted in low-to-high order within each byte. If \fIarg\fR
|
111 |
|
|
has fewer than \fIcount\fR digits, then zeros will be used for the
|
112 |
|
|
remaining digits. If \fIarg\fR has more than the specified number of
|
113 |
|
|
digits, the extra digits will be ignored. If \fIcount\fR is
|
114 |
|
|
\fB*\fR, then all of the digits in \fIarg\fR will be formatted. If
|
115 |
|
|
\fIcount\fR is omitted, then one digit will be formatted. If the
|
116 |
|
|
number of digits formatted does not end at a byte boundary, the
|
117 |
|
|
remaining bits of the last byte will be zeros. For example,
|
118 |
|
|
.RS
|
119 |
|
|
.CS
|
120 |
|
|
\fBbinary format h3h* AB def\fR
|
121 |
|
|
.CE
|
122 |
|
|
will return a string equivalent to \fB\\xba\\xed\\x0f\fR.
|
123 |
|
|
.RE
|
124 |
|
|
.IP \fBH\fR 5
|
125 |
|
|
This form is the same as \fBh\fR except that the digits are stored in
|
126 |
|
|
high-to-low order within each byte. For example,
|
127 |
|
|
.RS
|
128 |
|
|
.CS
|
129 |
|
|
\fBbinary format H3H* ab DEF\fR
|
130 |
|
|
.CE
|
131 |
|
|
will return a string equivalent to \fB\\xab\\xde\\xf0\fR.
|
132 |
|
|
.RE
|
133 |
|
|
.IP \fBc\fR 5
|
134 |
|
|
Stores one or more 8-bit integer values in the output string. If no
|
135 |
|
|
\fIcount\fR is specified, then \fIarg\fR must consist of an integer
|
136 |
|
|
value; otherwise \fIarg\fR must consist of a list containing at least
|
137 |
|
|
\fIcount\fR integer elements. The low-order 8 bits of each integer
|
138 |
|
|
are stored as a one-byte value at the cursor position. If \fIcount\fR
|
139 |
|
|
is \fB*\fR, then all of the integers in the list are formatted. If
|
140 |
|
|
the number of elements in the list is fewer than \fIcount\fR, then an
|
141 |
|
|
error is generated. If the number of elements in the list is greater
|
142 |
|
|
than \fIcount\fR, then the extra elements are ignored. For example,
|
143 |
|
|
.RS
|
144 |
|
|
.CS
|
145 |
|
|
\fBbinary format c3cc* {3 -3 128 1} 257 {2 5}\fR
|
146 |
|
|
.CE
|
147 |
|
|
will return a string equivalent to
|
148 |
|
|
\fB\\x03\\xfd\\x80\\x01\\x02\\x05\fR, whereas
|
149 |
|
|
.CS
|
150 |
|
|
\fBbinary format c {2 5}\fR
|
151 |
|
|
.CE
|
152 |
|
|
will generate an error.
|
153 |
|
|
.RE
|
154 |
|
|
.IP \fBs\fR 5
|
155 |
|
|
This form is the same as \fBc\fR except that it stores one or more
|
156 |
|
|
16-bit integers in little-endian byte order in the output string. The
|
157 |
|
|
low-order 16-bits of each integer are stored as a two-byte value at
|
158 |
|
|
the cursor position with the least significant byte stored first. For
|
159 |
|
|
example,
|
160 |
|
|
.RS
|
161 |
|
|
.CS
|
162 |
|
|
\fBbinary format s3 {3 -3 258 1}\fR
|
163 |
|
|
.CE
|
164 |
|
|
will return a string equivalent to
|
165 |
|
|
\fB\\x03\\x00\\xfd\\xff\\x02\\x01\fR.
|
166 |
|
|
.RE
|
167 |
|
|
.IP \fBS\fR 5
|
168 |
|
|
This form is the same as \fBs\fR except that it stores one or more
|
169 |
|
|
16-bit integers in big-endian byte order in the output string. For
|
170 |
|
|
example,
|
171 |
|
|
.RS
|
172 |
|
|
.CS
|
173 |
|
|
\fBbinary format S3 {3 -3 258 1}\fR
|
174 |
|
|
.CE
|
175 |
|
|
will return a string equivalent to
|
176 |
|
|
\fB\\x00\\x03\\xff\\xfd\\x01\\x02\fR.
|
177 |
|
|
.RE
|
178 |
|
|
.IP \fBi\fR 5
|
179 |
|
|
This form is the same as \fBc\fR except that it stores one or more
|
180 |
|
|
32-bit integers in little-endian byte order in the output string. The
|
181 |
|
|
low-order 32-bits of each integer are stored as a four-byte value at
|
182 |
|
|
the cursor position with the least significant byte stored first. For
|
183 |
|
|
example,
|
184 |
|
|
.RS
|
185 |
|
|
.CS
|
186 |
|
|
\fBbinary format i3 {3 -3 65536 1}\fR
|
187 |
|
|
.CE
|
188 |
|
|
will return a string equivalent to
|
189 |
|
|
\fB\\x03\\x00\\x00\\x00\\xfd\\xff\\xff\\xff\\x00\\x00\\x10\\x00\fR.
|
190 |
|
|
.RE
|
191 |
|
|
.IP \fBI\fR 5
|
192 |
|
|
This form is the same as \fBi\fR except that it stores one or more one
|
193 |
|
|
or more 32-bit integers in big-endian byte order in the output string.
|
194 |
|
|
For example,
|
195 |
|
|
.RS
|
196 |
|
|
.CS
|
197 |
|
|
\fBbinary format I3 {3 -3 65536 1}\fR
|
198 |
|
|
.CE
|
199 |
|
|
will return a string equivalent to
|
200 |
|
|
\fB\\x00\\x00\\x00\\x03\\xff\\xff\\xff\\xfd\\x00\\x10\\x00\\x00\fR.
|
201 |
|
|
.RE
|
202 |
|
|
.IP \fBf\fR 5
|
203 |
|
|
This form is the same as \fBc\fR except that it stores one or more one
|
204 |
|
|
or more single-precision floating in the machine's native
|
205 |
|
|
representation in the output string. This representation is not
|
206 |
|
|
portable across architectures, so it should not be used to communicate
|
207 |
|
|
floating point numbers across the network. The size of a floating
|
208 |
|
|
point number may vary across architectures, so the number of bytes
|
209 |
|
|
that are generated may vary. If the value overflows the
|
210 |
|
|
machine's native representation, then the value of FLT_MAX
|
211 |
|
|
as defined by the system will be used instead. Because Tcl uses
|
212 |
|
|
double-precision floating-point numbers internally, there may be some
|
213 |
|
|
loss of precision in the conversion to single-precision. For example,
|
214 |
|
|
on a Windows system running on an Intel Pentium processor,
|
215 |
|
|
.RS
|
216 |
|
|
.CS
|
217 |
|
|
\fBbinary format f2 {1.6 3.4}\fR
|
218 |
|
|
.CE
|
219 |
|
|
will return a string equivalent to
|
220 |
|
|
\fB\\xcd\\xcc\\xcc\\x3f\\x9a\\x99\\x59\\x40\fR.
|
221 |
|
|
.RE
|
222 |
|
|
.IP \fBd\fR 5
|
223 |
|
|
This form is the same as \fBf\fR except that it stores one or more one
|
224 |
|
|
or more double-precision floating in the machine's native
|
225 |
|
|
representation in the output string. For example, on a
|
226 |
|
|
Windows system running on an Intel Pentium processor,
|
227 |
|
|
.RS
|
228 |
|
|
.CS
|
229 |
|
|
\fBbinary format d1 {1.6}\fR
|
230 |
|
|
.CE
|
231 |
|
|
will return a string equivalent to
|
232 |
|
|
\fB\\x9a\\x99\\x99\\x99\\x99\\x99\\xf9\\x3f\fR.
|
233 |
|
|
.RE
|
234 |
|
|
.IP \fBx\fR 5
|
235 |
|
|
Stores \fIcount\fR null bytes in the output string. If \fIcount\fR is
|
236 |
|
|
not specified, stores one null byte. If \fIcount\fR is \fB*\fR,
|
237 |
|
|
generates an error. This type does not consume an argument. For
|
238 |
|
|
example,
|
239 |
|
|
.RS
|
240 |
|
|
.CS
|
241 |
|
|
\fBbinary format a3xa3x2a3 abc def ghi\fR
|
242 |
|
|
.CE
|
243 |
|
|
will return a string equivalent to \fBabc\\000def\\000\\000ghi\fR.
|
244 |
|
|
.RE
|
245 |
|
|
.IP \fBX\fR 5
|
246 |
|
|
Moves the cursor back \fIcount\fR bytes in the output string. If
|
247 |
|
|
\fIcount\fR is \fB*\fR or is larger than the current cursor position,
|
248 |
|
|
then the cursor is positioned at location 0 so that the next byte
|
249 |
|
|
stored will be the first byte in the result string. If \fIcount\fR is
|
250 |
|
|
omitted then the cursor is moved back one byte. This type does not
|
251 |
|
|
consume an argument. For example,
|
252 |
|
|
.RS
|
253 |
|
|
.CS
|
254 |
|
|
\fBbinary format a3X*a3X2a3 abc def ghi\fR
|
255 |
|
|
.CE
|
256 |
|
|
will return \fBdghi\fR.
|
257 |
|
|
.RE
|
258 |
|
|
.IP \fB@\fR 5
|
259 |
|
|
Moves the cursor to the absolute location in the output string
|
260 |
|
|
specified by \fIcount\fR. Position 0 refers to the first byte in the
|
261 |
|
|
output string. If \fIcount\fR refers to a position beyond the last
|
262 |
|
|
byte stored so far, then null bytes will be placed in the unitialized
|
263 |
|
|
locations and the cursor will be placed at the specified location. If
|
264 |
|
|
\fIcount\fR is \fB*\fR, then the cursor is moved to the current end of
|
265 |
|
|
the output string. If \fIcount\fR is omitted, then an error will be
|
266 |
|
|
generated. This type does not consume an argument. For example,
|
267 |
|
|
.RS
|
268 |
|
|
.CS
|
269 |
|
|
\fBbinary format a5@2a1@*a3@10a1 abcde f ghi j\fR
|
270 |
|
|
.CE
|
271 |
|
|
will return \fBabfdeghi\\000\\000j\fR.
|
272 |
|
|
.RE
|
273 |
|
|
|
274 |
|
|
.SH "BINARY SCAN"
|
275 |
|
|
.PP
|
276 |
|
|
The \fBbinary scan\fR command parses fields from a binary string,
|
277 |
|
|
returning the number of conversions performed. \fIString\fR gives the
|
278 |
|
|
input to be parsed and \fIformatString\fR indicates how to parse it.
|
279 |
|
|
Each \fIvarName\fR gives the name of a variable; when a field is
|
280 |
|
|
scanned from \fIstring\fR the result is assigned to the corresponding
|
281 |
|
|
variable.
|
282 |
|
|
.PP
|
283 |
|
|
As with \fBbinary format\fR, the \fIformatString\fR consists of a
|
284 |
|
|
sequence of zero or more field specifiers separated by zero or more
|
285 |
|
|
spaces. Each field specifier is a single type character followed by
|
286 |
|
|
an optional numeric \fIcount\fR. Most field specifiers consume one
|
287 |
|
|
argument to obtain the variable into which the scanned values should
|
288 |
|
|
be placed. The type character specifies how the binary data is to be
|
289 |
|
|
interpreted. The \fIcount\fR typically indicates how many items of
|
290 |
|
|
the specified type are taken from the data. If present, the
|
291 |
|
|
\fIcount\fR is a non-negative decimal integer or \fB*\fR, which
|
292 |
|
|
normally indicates that all of the remaining items in the data are to
|
293 |
|
|
be used. If there are not enough bytes left after the current cursor
|
294 |
|
|
position to satisfy the current field specifier, then the
|
295 |
|
|
corresponding variable is left untouched and \fBbinary scan\fR returns
|
296 |
|
|
immediately with the number of variables that were set. If there are
|
297 |
|
|
not enough arguments for all of the fields in the format string that
|
298 |
|
|
consume arguments, then an error is generated.
|
299 |
|
|
.PP
|
300 |
|
|
Each type-count pair moves an imaginary cursor through the binary data,
|
301 |
|
|
reading bytes from the current position. The cursor is initially
|
302 |
|
|
at position 0 at the beginning of the data. The type may be any one of
|
303 |
|
|
the following characters:
|
304 |
|
|
.IP \fBa\fR 5
|
305 |
|
|
The data is a character string of length \fIcount\fR. If \fIcount\fR
|
306 |
|
|
is \fB*\fR, then all of the remaining bytes in \fIstring\fR will be
|
307 |
|
|
scanned into the variable. If \fIcount\fR is omitted, then one
|
308 |
|
|
character will be scanned. For example,
|
309 |
|
|
.RS
|
310 |
|
|
.CS
|
311 |
|
|
\fBbinary scan abcde\\000fghi a6a10 var1 var2\fR
|
312 |
|
|
.CE
|
313 |
|
|
will return \fB1\fR with the string equivalent to \fBabcde\\000\fR
|
314 |
|
|
stored in \fBvar1\fR and \fBvar2\fR left unmodified.
|
315 |
|
|
.RE
|
316 |
|
|
.IP \fBA\fR 5
|
317 |
|
|
This form is the same as \fBa\fR, except trailing blanks and nulls are stripped from
|
318 |
|
|
the scanned value before it is stored in the variable. For example,
|
319 |
|
|
.RS
|
320 |
|
|
.CS
|
321 |
|
|
\fBbinary scan "abc efghi \\000" a* var1\fR
|
322 |
|
|
.CE
|
323 |
|
|
will return \fB1\fR with \fBabc efghi\fR stored in \fBvar1\fR.
|
324 |
|
|
.RE
|
325 |
|
|
.IP \fBb\fR 5
|
326 |
|
|
The data is turned into a string of \fIcount\fR binary digits in
|
327 |
|
|
low-to-high order represented as a sequence of ``1'' and ``0''
|
328 |
|
|
characters. The data bytes are scanned in first to last order with
|
329 |
|
|
the bits being taken in low-to-high order within each byte. Any extra
|
330 |
|
|
bits in the last byte are ignored. If \fIcount\fR is \fB*\fR, then
|
331 |
|
|
all of the remaining bits in \fBstring\fR will be scanned. If
|
332 |
|
|
\fIcount\fR is omitted, then one bit will be scanned. For example,
|
333 |
|
|
.RS
|
334 |
|
|
.CS
|
335 |
|
|
\fBbinary scan \\x07\\x87\\x05 b5b* var1 var2\fR
|
336 |
|
|
.CE
|
337 |
|
|
will return \fB2\fR with \fB11100\fR stored in \fBvar1\fR and
|
338 |
|
|
\fB1110000110100000\fR stored in \fBvar2\fR.
|
339 |
|
|
.RE
|
340 |
|
|
.IP \fBB\fR 5
|
341 |
|
|
This form is the same as \fBB\fR, except the bits are taken in
|
342 |
|
|
high-to-low order within each byte. For example,
|
343 |
|
|
.RS
|
344 |
|
|
.CS
|
345 |
|
|
\fBbinary scan \\x70\\x87\\x05 b5b* var1 var2\fR
|
346 |
|
|
.CE
|
347 |
|
|
will return \fB2\fR with \fB01110\fR stored in \fBvar1\fR and
|
348 |
|
|
\fB1000011100000101\fR stored in \fBvar2\fR.
|
349 |
|
|
.RE
|
350 |
|
|
.IP \fBh\fR 5
|
351 |
|
|
The data is turned into a string of \fIcount\fR hexadecimal digits in
|
352 |
|
|
low-to-high order represented as a sequence of characters in the set
|
353 |
|
|
``0123456789abcdef''. The data bytes are scanned in first to last
|
354 |
|
|
order with the hex digits being taken in low-to-high order within each
|
355 |
|
|
byte. Any extra bits in the last byte are ignored. If \fIcount\fR
|
356 |
|
|
is \fB*\fR, then all of the remaining hex digits in \fBstring\fR will be
|
357 |
|
|
scanned. If \fIcount\fR is omitted, then one hex digit will be
|
358 |
|
|
scanned. For example,
|
359 |
|
|
.RS
|
360 |
|
|
.CS
|
361 |
|
|
\fBbinary scan \\x07\\x86\\x05 h3h* var1 var2\fR
|
362 |
|
|
.CE
|
363 |
|
|
will return \fB2\fR with \fB706\fR stored in \fBvar1\fR and
|
364 |
|
|
\fB50\fR stored in \fBvar2\fR.
|
365 |
|
|
.RE
|
366 |
|
|
.IP \fBH\fR 5
|
367 |
|
|
This form is the same as \fBh\fR, except the digits are taken in
|
368 |
|
|
low-to-high order within each byte. For example,
|
369 |
|
|
.RS
|
370 |
|
|
.CS
|
371 |
|
|
\fBbinary scan \\x07\\x86\\x05 H3H* var1 var2\fR
|
372 |
|
|
.CE
|
373 |
|
|
will return \fB2\fR with \fB078\fR stored in \fBvar1\fR and
|
374 |
|
|
\fB05\fR stored in \fBvar2\fR.
|
375 |
|
|
.RE
|
376 |
|
|
.IP \fBc\fR 5
|
377 |
|
|
The data is turned into \fIcount\fR 8-bit signed integers and stored
|
378 |
|
|
in the corresponding variable as a list. If \fIcount\fR is \fB*\fR,
|
379 |
|
|
then all of the remaining bytes in \fBstring\fR will be scanned. If
|
380 |
|
|
\fIcount\fR is omitted, then one 8-bit integer will be scanned. For
|
381 |
|
|
example,
|
382 |
|
|
.RS
|
383 |
|
|
.CS
|
384 |
|
|
\fBbinary scan \\x07\\x86\\x05 c2c* var1 var2\fR
|
385 |
|
|
.CE
|
386 |
|
|
will return \fB2\fR with \fB7 -122\fR stored in \fBvar1\fR and \fB5\fR
|
387 |
|
|
stored in \fBvar2\fR. Note that the integers returned are signed, but
|
388 |
|
|
they can be converted to unsigned 8-bit quantities using an expression
|
389 |
|
|
like:
|
390 |
|
|
.CS
|
391 |
|
|
\fBexpr ( $num + 0x100 ) % 0x100\fR
|
392 |
|
|
.CE
|
393 |
|
|
.RE
|
394 |
|
|
.IP \fBs\fR 5
|
395 |
|
|
The data is interpreted as \fIcount\fR 16-bit signed integers
|
396 |
|
|
represented in little-endian byte order. The integers are stored in
|
397 |
|
|
the corresponding variable as a list. If \fIcount\fR is \fB*\fR, then
|
398 |
|
|
all of the remaining bytes in \fBstring\fR will be scanned. If
|
399 |
|
|
\fIcount\fR is omitted, then one 16-bit integer will be scanned. For
|
400 |
|
|
example,
|
401 |
|
|
.RS
|
402 |
|
|
.CS
|
403 |
|
|
\fBbinary scan \\x05\\x00\\x07\\x00\\xf0\\xff s2s* var1 var2\fR
|
404 |
|
|
.CE
|
405 |
|
|
will return \fB2\fR with \fB5 7\fR stored in \fBvar1\fR and \fB-16\fR
|
406 |
|
|
stored in \fBvar2\fR. Note that the integers returned are signed, but
|
407 |
|
|
they can be converted to unsigned 16-bit quantities using an expression
|
408 |
|
|
like:
|
409 |
|
|
.CS
|
410 |
|
|
\fBexpr ( $num + 0x10000 ) % 0x10000\fR
|
411 |
|
|
.CE
|
412 |
|
|
.RE
|
413 |
|
|
.IP \fBS\fR 5
|
414 |
|
|
This form is the same as \fBs\fR except that the data is interpreted
|
415 |
|
|
as \fIcount\fR 16-bit signed integers represented in big-endian byte
|
416 |
|
|
order. For example,
|
417 |
|
|
.RS
|
418 |
|
|
.CS
|
419 |
|
|
\fBbinary scan \\x00\\x05\\x00\\x07\\xff\\xf0 S2S* var1 var2\fR
|
420 |
|
|
.CE
|
421 |
|
|
will return \fB2\fR with \fB5 7\fR stored in \fBvar1\fR and \fB-16\fR
|
422 |
|
|
stored in \fBvar2\fR.
|
423 |
|
|
.RE
|
424 |
|
|
.IP \fBi\fR 5
|
425 |
|
|
The data is interpreted as \fIcount\fR 32-bit signed integers
|
426 |
|
|
represented in little-endian byte order. The integers are stored in
|
427 |
|
|
the corresponding variable as a list. If \fIcount\fR is \fB*\fR, then
|
428 |
|
|
all of the remaining bytes in \fBstring\fR will be scanned. If
|
429 |
|
|
\fIcount\fR is omitted, then one 32-bit integer will be scanned. For
|
430 |
|
|
example,
|
431 |
|
|
.RS
|
432 |
|
|
.CS
|
433 |
|
|
\fBbinary scan \\x05\\x00\\x00\\x00\\x07\\x00\\x00\\x00\\xf0\\xff\\xff\\xff i2i* var1 var2\fR
|
434 |
|
|
.CE
|
435 |
|
|
will return \fB2\fR with \fB5 7\fR stored in \fBvar1\fR and \fB-16\fR
|
436 |
|
|
stored in \fBvar2\fR. Note that the integers returned are signed and
|
437 |
|
|
cannot be represented by Tcl as unsigned values.
|
438 |
|
|
.RE
|
439 |
|
|
.IP \fBI\fR 5
|
440 |
|
|
This form is the same as \fBI\fR except that the data is interpreted
|
441 |
|
|
as \fIcount\fR 32-bit signed integers represented in big-endian byte
|
442 |
|
|
order. For example,
|
443 |
|
|
.RS
|
444 |
|
|
.CS
|
445 |
|
|
\fBbinary \\x00\\x00\\x00\\x05\\x00\\x00\\x00\\x07\\xff\\xff\\xff\\xf0 I2I* var1 var2\fR
|
446 |
|
|
.CE
|
447 |
|
|
will return \fB2\fR with \fB5 7\fR stored in \fBvar1\fR and \fB-16\fR
|
448 |
|
|
stored in \fBvar2\fR.
|
449 |
|
|
.RE
|
450 |
|
|
.IP \fBf\fR 5
|
451 |
|
|
The data is interpreted as \fIcount\fR single-precision floating point
|
452 |
|
|
numbers in the machine's native representation. The floating point
|
453 |
|
|
numbers are stored in the corresponding variable as a list. If
|
454 |
|
|
\fIcount\fR is \fB*\fR, then all of the remaining bytes in
|
455 |
|
|
\fBstring\fR will be scanned. If \fIcount\fR is omitted, then one
|
456 |
|
|
single-precision floating point number will be scanned. The size of a
|
457 |
|
|
floating point number may vary across architectures, so the number of
|
458 |
|
|
bytes that are scanned may vary. If the data does not represent a
|
459 |
|
|
valid floating point number, the resulting value is undefined and
|
460 |
|
|
compiler dependent. For example, on a Windows system running on an
|
461 |
|
|
Intel Pentium processor,
|
462 |
|
|
.RS
|
463 |
|
|
.CS
|
464 |
|
|
\fBbinary scan \\x3f\\xcc\\xcc\\xcd f var1\fR
|
465 |
|
|
.CE
|
466 |
|
|
will return \fB1\fR with \fB1.6000000238418579\fR stored in
|
467 |
|
|
\fBvar1\fR.
|
468 |
|
|
.RE
|
469 |
|
|
.IP \fBd\fR 5
|
470 |
|
|
This form is the same as \fBf\fR except that the data is interpreted
|
471 |
|
|
as \fIcount\fR double-precision floating point numbers in the
|
472 |
|
|
machine's native representation. For example, on a Windows system
|
473 |
|
|
running on an Intel Pentium processor,
|
474 |
|
|
.RS
|
475 |
|
|
.CS
|
476 |
|
|
\fBbinary scan \\x9a\\x99\\x99\\x99\\x99\\x99\\xf9\\x3f d var1\fR
|
477 |
|
|
.CE
|
478 |
|
|
will return \fB1\fR with \fB1.6000000000000001\fR
|
479 |
|
|
stored in \fBvar1\fR.
|
480 |
|
|
.RE
|
481 |
|
|
.IP \fBx\fR 5
|
482 |
|
|
Moves the cursor forward \fIcount\fR bytes in \fIstring\fR. If
|
483 |
|
|
\fIcount\fR is \fB*\fR or is larger than the number of bytes after the
|
484 |
|
|
current cursor cursor position, then the cursor is positioned after
|
485 |
|
|
the last byte in \fIstring\fR. If \fIcount\fR is omitted, then the
|
486 |
|
|
cursor is moved forward one byte. Note that this type does not
|
487 |
|
|
consume an argument. For example,
|
488 |
|
|
.RS
|
489 |
|
|
.CS
|
490 |
|
|
\fBbinary scan \\x01\\x02\\x03\\x04 x2H* var1\fR
|
491 |
|
|
.CE
|
492 |
|
|
will return \fB1\fR with \fB0304\fR stored in \fBvar1\fR.
|
493 |
|
|
.RE
|
494 |
|
|
.IP \fBX\fR 5
|
495 |
|
|
Moves the cursor back \fIcount\fR bytes in \fIstring\fR. If
|
496 |
|
|
\fIcount\fR is \fB*\fR or is larger than the current cursor position,
|
497 |
|
|
then the cursor is positioned at location 0 so that the next byte
|
498 |
|
|
scanned will be the first byte in \fIstring\fR. If \fIcount\fR
|
499 |
|
|
is omitted then the cursor is moved back one byte. Note that this
|
500 |
|
|
type does not consume an argument. For example,
|
501 |
|
|
.RS
|
502 |
|
|
.CS
|
503 |
|
|
\fBbinary scan \\x01\\x02\\x03\\x04 c2XH* var1 var2\fR
|
504 |
|
|
.CE
|
505 |
|
|
will return \fB2\fR with \fB1 2\fR stored in \fBvar1\fR and \fB020304\fR
|
506 |
|
|
stored in \fBvar2\fR.
|
507 |
|
|
.RE
|
508 |
|
|
.IP \fB@\fR 5
|
509 |
|
|
Moves the cursor to the absolute location in the data string specified
|
510 |
|
|
by \fIcount\fR. Note that position 0 refers to the first byte in
|
511 |
|
|
\fIstring\fR. If \fIcount\fR refers to a position beyond the end of
|
512 |
|
|
\fIstring\fR, then the cursor is positioned after the last byte. If
|
513 |
|
|
\fIcount\fR is omitted, then an error will be generated. For example,
|
514 |
|
|
.RS
|
515 |
|
|
.CS
|
516 |
|
|
\fBbinary scan \\x01\\x02\\x03\\x04 c2@1H* var1 var2\fR
|
517 |
|
|
.CE
|
518 |
|
|
will return \fB2\fR with \fB1 2\fR stored in \fBvar1\fR and \fB020304\fR
|
519 |
|
|
stored in \fBvar2\fR.
|
520 |
|
|
.RE
|
521 |
|
|
|
522 |
|
|
.SH "PLATFORM ISSUES"
|
523 |
|
|
Sometimes it is desirable to format or scan integer values in the
|
524 |
|
|
native byte order for the machine. Refer to the \fBbyteOrder\fR
|
525 |
|
|
element of the \fBtcl_platform\fR array to decide which type character
|
526 |
|
|
to use when formatting or scanning integers.
|
527 |
|
|
|
528 |
|
|
.SH "SEE ALSO"
|
529 |
|
|
format, scan, tclvars
|
530 |
|
|
|
531 |
|
|
.SH KEYWORDS
|
532 |
|
|
binary, format, scan
|