1 .\" Copyright (c) 1990, 1991 The Regents of the University of California.
2 .\" All rights reserved.
4 .\" This code is derived from software contributed to Berkeley by
5 .\" Chris Torek and the American National Standards Committee X3,
6 .\" on Information Processing Systems.
8 .\" Redistribution and use in source and binary forms, with or without
9 .\" modification, are permitted provided that the following conditions
11 .\" 1. Redistributions of source code must retain the above copyright
12 .\" notice, this list of conditions and the following disclaimer.
13 .\" 2. Redistributions in binary form must reproduce the above copyright
14 .\" notice, this list of conditions and the following disclaimer in the
15 .\" documentation and/or other materials provided with the distribution.
16 .\" 3. All advertising materials mentioning features or use of this software
17 .\" must display the following acknowledgement:
18 .\" This product includes software developed by the University of
19 .\" California, Berkeley and its contributors.
20 .\" 4. Neither the name of the University nor the names of its contributors
21 .\" may be used to endorse or promote products derived from this software
22 .\" without specific prior written permission.
24 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
25 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
26 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
27 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
28 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
29 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
30 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
31 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
32 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
33 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
36 .\" @(#)scanf.3 6.14 (Berkeley) 1/8/93
38 .\" Converted for Linux, Mon Nov 29 15:22:01 1993, faith@cs.unc.edu
39 .\" modified to resemble the GNU libio setup used in the Linux libc
40 .\" used in versions 4.x (x>4) and 5 Helmut.Geyer@iwr.uni-heidelberg.de
41 .\" Modified, aeb, 970121
42 .\" 2005-07-14, mtk, added description of %n$ form; various text
43 .\" incorporated from the GNU C library documentation ((C) The
44 .\" Free Software Foundation); other parts substantially rewritten.
47 .\" The glibc 2.7 release announcement says:
48 .\" Implement 'm' modifier for scanf. Add stricter C99/SUS compliance
49 .\" by not recognizing 'a' as a modifier when those specs are requested.
50 .\" These changes need to be documented.
52 .TH SCANF 3 2007-07-26 "GNU" "Linux Programmer's Manual"
54 scanf, fscanf, sscanf, vscanf, vsscanf, vfscanf \- input format conversion
59 .BI "int scanf(const char *" format ", ...);"
60 .BI "int fscanf(FILE *" stream ", const char *" format ", ...);"
61 .BI "int sscanf(const char *" str ", const char *" format ", ...);"
63 .B #include <stdarg.h>
65 .BI "int vscanf(const char *" format ", va_list " ap );
66 .BI "int vsscanf(const char *" str ", const char *" format ", va_list " ap );
67 .BI "int vfscanf(FILE *" stream ", const char *" format ", va_list " ap );
71 Feature Test Macro Requirements for glibc (see
72 .BR feature_test_macros (7)):
78 _XOPEN_SOURCE\ >=\ 600 || _ISOC99_SOURCE; or
83 family of functions scans input according to
86 This format may contain
87 .IR "conversion specifications" ;
88 the results from such conversions, if any,
89 are stored in the locations pointed to by the
95 argument must be of a type that is appropriate for the value returned
96 by the corresponding conversion specification.
98 If the number of conversion specifications in
100 exceeds the number of
102 arguments, the results are undefined.
105 arguments exceeds the number of conversion specifications, then the excess
107 arguments are evaluated, but are otherwise ignored.
111 function reads input from the standard input stream
114 reads input from the stream pointer
118 reads its input from the character string pointed to by
123 function is analogous to
125 and reads input from the stream pointer
127 using a variable argument list of pointers (see
131 function scans a variable argument list from the standard input and the
133 function scans it from a string; these are analogous to the
137 functions respectively.
141 string consists of a sequence of
143 which describe how to process the sequence of input characters.
144 If processing of a directive fails, no further input is read, and
147 A "failure" can be either of the following:
148 .IR "input failure" ,
149 meaning that input characters were unavailable, or
150 .IR "matching failure" ,
151 meaning that the input was inappropriate (see below).
153 A directive is one of the following:
156 A sequence of white-space characters (space, tab, newline, etc.; see
158 This directive matches any amount of white space,
159 including none, in the input.
162 An ordinary character (i.e., one other than white space or '%').
163 This character must exactly match the next character of input.
166 A conversion specification, which commences with a '%' (percent) character.
167 A sequence of characters from the input is converted according to
168 this specification, and the result is placed in the corresponding
171 If the next item of input does not match the conversion specification,
172 the conversion fails \(em this is a
173 .IR "matching failure" .
176 .I conversion specification
179 begins with either the character '%' or the character sequence
180 "\fB%\fP\fIn\fP\fB$\fP"
181 (see below for the distinction) followed by:
184 An optional '*' assignment-suppression character:
186 reads input as directed by the conversion specification,
187 but discards the input.
190 argument is required, and this specification is not
191 included in the count of successful assignments returned by
195 An optional 'a' character.
196 This is used with string conversions, and relieves the caller of the
197 need to allocate a corresponding buffer to hold the input: instead,
199 allocates a buffer of sufficient size,
200 and assigns the address of this buffer to the corresponding
202 argument, which should be a pointer to a
204 variable (this variable does not need to be initialized before the call).
205 The caller should subsequently
207 this buffer when it is no longer required.
208 This is a GNU extension;
209 C99 employs the 'a' character as a conversion specifier (and
210 it can also be used as such in the GNU implementation).
213 An optional decimal integer which specifies the
214 .IR "maximum field width" .
215 Reading of characters stops either when this maximum is reached or
216 when a non-matching character is found, whichever happens first.
217 Most conversions discard initial whitespace characters (the exceptions
219 and these discarded characters don't count towards the maximum field width.
220 String input conversions store a null terminator ('\\0')
221 to mark the end of the input;
222 the maximum field width does not include this terminator.
226 .IR "type modifier character" .
229 type modifier is used with integer conversions such as
231 to specify that the corresponding
235 rather than a pointer to an
240 .I "conversion specifier"
241 that specifies the type of input conversion to be performed.
243 The conversion specifications in
245 are of two forms, either beginning with '%' or beginning with
246 "\fB%\fP\fIn\fP\fB$\fP".
247 The two forms should not be mixed in the same
249 string, except that a string containing
250 "\fB%\fP\fIn\fP\fB$\fP"
251 specifications can include
258 specifications then these correspond in order with successive
262 "\fB%\fP\fIn\fP\fB$\fP"
263 form (which is specified in POSIX.1-2001, but not C99),
265 is a decimal integer that specifies that the converted input should
266 be placed in the location referred to by the
273 .I "type modifier characters"
274 can appear in a conversion specification:
277 Indicates that the conversion will be one of
281 and the next pointer is a pointer to a
284 .I unsigned short int
291 but the next pointer is a pointer to a
294 .IR "unsigned char" .
299 but the next pointer is a pointer to an
303 This modifier was introduced in C99.
306 Indicates either that the conversion will be one of
310 and the next pointer is a pointer to a
316 or that the conversion will be one of
318 and the next pointer is a pointer to
324 characters is equivalent to
330 the corresponding parameter is considered
331 as a pointer to a wide character or wide-character string respectively.
332 .\" This use of l was introduced in Amendment 1 to ISO C90.
335 Indicates that the conversion will be either
337 and the next pointer is a pointer to
339 or the conversion will be
341 and the next pointer is a pointer to
343 .\" MTK, Jul 05: The following is no longer true for modern
344 .\" ANSI C (i.e., C99):
345 .\" (Note that long long is not an
347 .\" type. Any program using this will not be portable to all
353 This specifier does not exist in ANSI C.
358 but the next pointer is a pointer to a
360 This modifier was introduced in C99.
365 but the next pointer is a pointer to a
367 This modifier was introduced in C99.
370 .I "conversion specifiers"
374 Matches a literal '%'.
377 in the format string matches a
378 single input '%' character.
379 No conversion is done, and assignment does not
383 Matches an optionally signed decimal integer;
384 the next pointer must be a pointer to
390 this exists only for backwards compatibility.
391 (Note: thus only in libc4.
392 In libc5 and glibc the
394 is silently ignored, causing old programs to fail mysteriously.)
397 Matches an optionally signed integer; the next pointer must be a pointer to
399 The integer is read in base 16 if it begins with
403 in base 8 if it begins with
405 and in base 10 otherwise.
406 Only characters that correspond to the base are used.
409 Matches an unsigned octal integer; the next pointer must be a pointer to
413 Matches an unsigned decimal integer; the next pointer must be a
418 Matches an unsigned hexadecimal integer; the next pointer must
427 Matches an optionally signed floating-point number; the next pointer must
448 Matches a sequence of non-white-space characters;
449 the next pointer must be a pointer to character array that is
450 long enough to hold the input sequence and the terminating null
451 character ('\\0'), which is added automatically.
452 The input string stops at white space or at the maximum field
453 width, whichever occurs first.
456 Matches a sequence of characters whose length is specified by the
457 .I maximum field width
458 (default 1); the next pointer must be a pointer to
460 and there must be enough room for all the characters (no terminating
463 The usual skip of leading white space is suppressed.
464 To skip white space first, use an explicit space in the format.
467 Matches a nonempty sequence of characters from the specified set of
468 accepted characters; the next pointer must be a pointer to
470 and there must be enough room for all the characters in the string, plus a
471 terminating null byte.
472 The usual skip of leading white space is suppressed.
473 The string is to be made up of characters in (or not in) a particular set;
474 the set is defined by the characters between the open bracket
476 character and a close bracket
481 those characters if the first character after the open bracket is a
484 To include a close bracket in the set, make it the first character after
485 the open bracket or the circumflex; any other position will end the set.
488 is also special; when placed between two other characters, it adds all
489 intervening characters to the set.
490 To include a hyphen, make it the last
491 character before the final close bracket.
495 the set "everything except close bracket, zero through nine, and hyphen".
496 The string ends with the appearance of a character not in the (or, with a
497 circumflex, in) set or when the field width runs out.
500 Matches a pointer value (as printed by
504 the next pointer must be a pointer to a pointer to
508 Nothing is expected; instead, the number of characters consumed thus far
509 from the input is stored through the next pointer, which must be a pointer
514 a conversion, although it can be suppressed with the
516 assignment-suppression character.
517 The C standard says: "Execution of a
519 directive does not increment
520 the assignment count returned at the completion of execution"
521 but the Corrigendum seems to contradict this.
523 not to make any assumptions on the effect of
525 conversions on the return value.
527 These functions return the number of input items
528 successfully matched and assigned,
529 which can be fewer than provided for,
530 or even zero in the event of an early matching failure.
534 is returned if the end of input is reached before either the first
535 successful conversion or a matching failure occurs.
537 is also returned if a read error occurs,
538 in which case the error indicator for the stream (see
542 is set indicate the error.
549 conform to C89 and C99.
553 specifier is the 4.4BSD notation for
559 in integer conversions is the GNU notation.
561 The Linux version of these functions is based on the
570 for a more concise description.
572 All functions are fully C89 conformant, but provide the
573 additional specifiers
577 as well as an additional behavior of the
582 The latter may be considered to be a bug, as it changes the
583 behavior of specifiers defined in C89.
585 Some combinations of the type modifiers and conversion
586 specifiers defined by ANSI C do not make sense
589 While they may have a well-defined behavior on Linux, this need not
590 to be so on other architectures.
591 Therefore it usually is better to use
592 modifiers that are not defined by ANSI C at all, that is, use
603 is not the same as on 4.4BSD,
604 as it may be used in float conversions equivalently to