]> git.ipfire.org Git - thirdparty/glibc.git/blob - manual/string.texi
Merge glibc-ports into ports/ directory.
[thirdparty/glibc.git] / manual / string.texi
1 @node String and Array Utilities, Character Set Handling, Character Handling, Top
2 @c %MENU% Utilities for copying and comparing strings and arrays
3 @chapter String and Array Utilities
4
5 Operations on strings (or arrays of characters) are an important part of
6 many programs. @Theglibc{} provides an extensive set of string
7 utility functions, including functions for copying, concatenating,
8 comparing, and searching strings. Many of these functions can also
9 operate on arbitrary regions of storage; for example, the @code{memcpy}
10 function can be used to copy the contents of any kind of array.
11
12 It's fairly common for beginning C programmers to ``reinvent the wheel''
13 by duplicating this functionality in their own code, but it pays to
14 become familiar with the library functions and to make use of them,
15 since this offers benefits in maintenance, efficiency, and portability.
16
17 For instance, you could easily compare one string to another in two
18 lines of C code, but if you use the built-in @code{strcmp} function,
19 you're less likely to make a mistake. And, since these library
20 functions are typically highly optimized, your program may run faster
21 too.
22
23 @menu
24 * Representation of Strings:: Introduction to basic concepts.
25 * String/Array Conventions:: Whether to use a string function or an
26 arbitrary array function.
27 * String Length:: Determining the length of a string.
28 * Copying and Concatenation:: Functions to copy the contents of strings
29 and arrays.
30 * String/Array Comparison:: Functions for byte-wise and character-wise
31 comparison.
32 * Collation Functions:: Functions for collating strings.
33 * Search Functions:: Searching for a specific element or substring.
34 * Finding Tokens in a String:: Splitting a string into tokens by looking
35 for delimiters.
36 * strfry:: Function for flash-cooking a string.
37 * Trivial Encryption:: Obscuring data.
38 * Encode Binary Data:: Encoding and Decoding of Binary Data.
39 * Argz and Envz Vectors:: Null-separated string vectors.
40 @end menu
41
42 @node Representation of Strings
43 @section Representation of Strings
44 @cindex string, representation of
45
46 This section is a quick summary of string concepts for beginning C
47 programmers. It describes how character strings are represented in C
48 and some common pitfalls. If you are already familiar with this
49 material, you can skip this section.
50
51 @cindex string
52 @cindex multibyte character string
53 A @dfn{string} is an array of @code{char} objects. But string-valued
54 variables are usually declared to be pointers of type @code{char *}.
55 Such variables do not include space for the text of a string; that has
56 to be stored somewhere else---in an array variable, a string constant,
57 or dynamically allocated memory (@pxref{Memory Allocation}). It's up to
58 you to store the address of the chosen memory space into the pointer
59 variable. Alternatively you can store a @dfn{null pointer} in the
60 pointer variable. The null pointer does not point anywhere, so
61 attempting to reference the string it points to gets an error.
62
63 @cindex wide character string
64 ``string'' normally refers to multibyte character strings as opposed to
65 wide character strings. Wide character strings are arrays of type
66 @code{wchar_t} and as for multibyte character strings usually pointers
67 of type @code{wchar_t *} are used.
68
69 @cindex null character
70 @cindex null wide character
71 By convention, a @dfn{null character}, @code{'\0'}, marks the end of a
72 multibyte character string and the @dfn{null wide character},
73 @code{L'\0'}, marks the end of a wide character string. For example, in
74 testing to see whether the @code{char *} variable @var{p} points to a
75 null character marking the end of a string, you can write
76 @code{!*@var{p}} or @code{*@var{p} == '\0'}.
77
78 A null character is quite different conceptually from a null pointer,
79 although both are represented by the integer @code{0}.
80
81 @cindex string literal
82 @dfn{String literals} appear in C program source as strings of
83 characters between double-quote characters (@samp{"}) where the initial
84 double-quote character is immediately preceded by a capital @samp{L}
85 (ell) character (as in @code{L"foo"}). In @w{ISO C}, string literals
86 can also be formed by @dfn{string concatenation}: @code{"a" "b"} is the
87 same as @code{"ab"}. For wide character strings one can either use
88 @code{L"a" L"b"} or @code{L"a" "b"}. Modification of string literals is
89 not allowed by the GNU C compiler, because literals are placed in
90 read-only storage.
91
92 Character arrays that are declared @code{const} cannot be modified
93 either. It's generally good style to declare non-modifiable string
94 pointers to be of type @code{const char *}, since this often allows the
95 C compiler to detect accidental modifications as well as providing some
96 amount of documentation about what your program intends to do with the
97 string.
98
99 The amount of memory allocated for the character array may extend past
100 the null character that normally marks the end of the string. In this
101 document, the term @dfn{allocated size} is always used to refer to the
102 total amount of memory allocated for the string, while the term
103 @dfn{length} refers to the number of characters up to (but not
104 including) the terminating null character.
105 @cindex length of string
106 @cindex allocation size of string
107 @cindex size of string
108 @cindex string length
109 @cindex string allocation
110
111 A notorious source of program bugs is trying to put more characters in a
112 string than fit in its allocated size. When writing code that extends
113 strings or moves characters into a pre-allocated array, you should be
114 very careful to keep track of the length of the text and make explicit
115 checks for overflowing the array. Many of the library functions
116 @emph{do not} do this for you! Remember also that you need to allocate
117 an extra byte to hold the null character that marks the end of the
118 string.
119
120 @cindex single-byte string
121 @cindex multibyte string
122 Originally strings were sequences of bytes where each byte represents a
123 single character. This is still true today if the strings are encoded
124 using a single-byte character encoding. Things are different if the
125 strings are encoded using a multibyte encoding (for more information on
126 encodings see @ref{Extended Char Intro}). There is no difference in
127 the programming interface for these two kind of strings; the programmer
128 has to be aware of this and interpret the byte sequences accordingly.
129
130 But since there is no separate interface taking care of these
131 differences the byte-based string functions are sometimes hard to use.
132 Since the count parameters of these functions specify bytes a call to
133 @code{strncpy} could cut a multibyte character in the middle and put an
134 incomplete (and therefore unusable) byte sequence in the target buffer.
135
136 @cindex wide character string
137 To avoid these problems later versions of the @w{ISO C} standard
138 introduce a second set of functions which are operating on @dfn{wide
139 characters} (@pxref{Extended Char Intro}). These functions don't have
140 the problems the single-byte versions have since every wide character is
141 a legal, interpretable value. This does not mean that cutting wide
142 character strings at arbitrary points is without problems. It normally
143 is for alphabet-based languages (except for non-normalized text) but
144 languages based on syllables still have the problem that more than one
145 wide character is necessary to complete a logical unit. This is a
146 higher level problem which the @w{C library} functions are not designed
147 to solve. But it is at least good that no invalid byte sequences can be
148 created. Also, the higher level functions can also much easier operate
149 on wide character than on multibyte characters so that a general advise
150 is to use wide characters internally whenever text is more than simply
151 copied.
152
153 The remaining of this chapter will discuss the functions for handling
154 wide character strings in parallel with the discussion of the multibyte
155 character strings since there is almost always an exact equivalent
156 available.
157
158 @node String/Array Conventions
159 @section String and Array Conventions
160
161 This chapter describes both functions that work on arbitrary arrays or
162 blocks of memory, and functions that are specific to null-terminated
163 arrays of characters and wide characters.
164
165 Functions that operate on arbitrary blocks of memory have names
166 beginning with @samp{mem} and @samp{wmem} (such as @code{memcpy} and
167 @code{wmemcpy}) and invariably take an argument which specifies the size
168 (in bytes and wide characters respectively) of the block of memory to
169 operate on. The array arguments and return values for these functions
170 have type @code{void *} or @code{wchar_t}. As a matter of style, the
171 elements of the arrays used with the @samp{mem} functions are referred
172 to as ``bytes''. You can pass any kind of pointer to these functions,
173 and the @code{sizeof} operator is useful in computing the value for the
174 size argument. Parameters to the @samp{wmem} functions must be of type
175 @code{wchar_t *}. These functions are not really usable with anything
176 but arrays of this type.
177
178 In contrast, functions that operate specifically on strings and wide
179 character strings have names beginning with @samp{str} and @samp{wcs}
180 respectively (such as @code{strcpy} and @code{wcscpy}) and look for a
181 null character to terminate the string instead of requiring an explicit
182 size argument to be passed. (Some of these functions accept a specified
183 maximum length, but they also check for premature termination with a
184 null character.) The array arguments and return values for these
185 functions have type @code{char *} and @code{wchar_t *} respectively, and
186 the array elements are referred to as ``characters'' and ``wide
187 characters''.
188
189 In many cases, there are both @samp{mem} and @samp{str}/@samp{wcs}
190 versions of a function. The one that is more appropriate to use depends
191 on the exact situation. When your program is manipulating arbitrary
192 arrays or blocks of storage, then you should always use the @samp{mem}
193 functions. On the other hand, when you are manipulating null-terminated
194 strings it is usually more convenient to use the @samp{str}/@samp{wcs}
195 functions, unless you already know the length of the string in advance.
196 The @samp{wmem} functions should be used for wide character arrays with
197 known size.
198
199 @cindex wint_t
200 @cindex parameter promotion
201 Some of the memory and string functions take single characters as
202 arguments. Since a value of type @code{char} is automatically promoted
203 into an value of type @code{int} when used as a parameter, the functions
204 are declared with @code{int} as the type of the parameter in question.
205 In case of the wide character function the situation is similarly: the
206 parameter type for a single wide character is @code{wint_t} and not
207 @code{wchar_t}. This would for many implementations not be necessary
208 since the @code{wchar_t} is large enough to not be automatically
209 promoted, but since the @w{ISO C} standard does not require such a
210 choice of types the @code{wint_t} type is used.
211
212 @node String Length
213 @section String Length
214
215 You can get the length of a string using the @code{strlen} function.
216 This function is declared in the header file @file{string.h}.
217 @pindex string.h
218
219 @comment string.h
220 @comment ISO
221 @deftypefun size_t strlen (const char *@var{s})
222 The @code{strlen} function returns the length of the null-terminated
223 string @var{s} in bytes. (In other words, it returns the offset of the
224 terminating null character within the array.)
225
226 For example,
227 @smallexample
228 strlen ("hello, world")
229 @result{} 12
230 @end smallexample
231
232 When applied to a character array, the @code{strlen} function returns
233 the length of the string stored there, not its allocated size. You can
234 get the allocated size of the character array that holds a string using
235 the @code{sizeof} operator:
236
237 @smallexample
238 char string[32] = "hello, world";
239 sizeof (string)
240 @result{} 32
241 strlen (string)
242 @result{} 12
243 @end smallexample
244
245 But beware, this will not work unless @var{string} is the character
246 array itself, not a pointer to it. For example:
247
248 @smallexample
249 char string[32] = "hello, world";
250 char *ptr = string;
251 sizeof (string)
252 @result{} 32
253 sizeof (ptr)
254 @result{} 4 /* @r{(on a machine with 4 byte pointers)} */
255 @end smallexample
256
257 This is an easy mistake to make when you are working with functions that
258 take string arguments; those arguments are always pointers, not arrays.
259
260 It must also be noted that for multibyte encoded strings the return
261 value does not have to correspond to the number of characters in the
262 string. To get this value the string can be converted to wide
263 characters and @code{wcslen} can be used or something like the following
264 code can be used:
265
266 @smallexample
267 /* @r{The input is in @code{string}.}
268 @r{The length is expected in @code{n}.} */
269 @{
270 mbstate_t t;
271 char *scopy = string;
272 /* In initial state. */
273 memset (&t, '\0', sizeof (t));
274 /* Determine number of characters. */
275 n = mbsrtowcs (NULL, &scopy, strlen (scopy), &t);
276 @}
277 @end smallexample
278
279 This is cumbersome to do so if the number of characters (as opposed to
280 bytes) is needed often it is better to work with wide characters.
281 @end deftypefun
282
283 The wide character equivalent is declared in @file{wchar.h}.
284
285 @comment wchar.h
286 @comment ISO
287 @deftypefun size_t wcslen (const wchar_t *@var{ws})
288 The @code{wcslen} function is the wide character equivalent to
289 @code{strlen}. The return value is the number of wide characters in the
290 wide character string pointed to by @var{ws} (this is also the offset of
291 the terminating null wide character of @var{ws}).
292
293 Since there are no multi wide character sequences making up one
294 character the return value is not only the offset in the array, it is
295 also the number of wide characters.
296
297 This function was introduced in @w{Amendment 1} to @w{ISO C90}.
298 @end deftypefun
299
300 @comment string.h
301 @comment GNU
302 @deftypefun size_t strnlen (const char *@var{s}, size_t @var{maxlen})
303 The @code{strnlen} function returns the length of the string @var{s} in
304 bytes if this length is smaller than @var{maxlen} bytes. Otherwise it
305 returns @var{maxlen}. Therefore this function is equivalent to
306 @code{(strlen (@var{s}) < @var{maxlen} ? strlen (@var{s}) : @var{maxlen})}
307 but it
308 is more efficient and works even if the string @var{s} is not
309 null-terminated.
310
311 @smallexample
312 char string[32] = "hello, world";
313 strnlen (string, 32)
314 @result{} 12
315 strnlen (string, 5)
316 @result{} 5
317 @end smallexample
318
319 This function is a GNU extension and is declared in @file{string.h}.
320 @end deftypefun
321
322 @comment wchar.h
323 @comment GNU
324 @deftypefun size_t wcsnlen (const wchar_t *@var{ws}, size_t @var{maxlen})
325 @code{wcsnlen} is the wide character equivalent to @code{strnlen}. The
326 @var{maxlen} parameter specifies the maximum number of wide characters.
327
328 This function is a GNU extension and is declared in @file{wchar.h}.
329 @end deftypefun
330
331 @node Copying and Concatenation
332 @section Copying and Concatenation
333
334 You can use the functions described in this section to copy the contents
335 of strings and arrays, or to append the contents of one string to
336 another. The @samp{str} and @samp{mem} functions are declared in the
337 header file @file{string.h} while the @samp{wstr} and @samp{wmem}
338 functions are declared in the file @file{wchar.h}.
339 @pindex string.h
340 @pindex wchar.h
341 @cindex copying strings and arrays
342 @cindex string copy functions
343 @cindex array copy functions
344 @cindex concatenating strings
345 @cindex string concatenation functions
346
347 A helpful way to remember the ordering of the arguments to the functions
348 in this section is that it corresponds to an assignment expression, with
349 the destination array specified to the left of the source array. All
350 of these functions return the address of the destination array.
351
352 Most of these functions do not work properly if the source and
353 destination arrays overlap. For example, if the beginning of the
354 destination array overlaps the end of the source array, the original
355 contents of that part of the source array may get overwritten before it
356 is copied. Even worse, in the case of the string functions, the null
357 character marking the end of the string may be lost, and the copy
358 function might get stuck in a loop trashing all the memory allocated to
359 your program.
360
361 All functions that have problems copying between overlapping arrays are
362 explicitly identified in this manual. In addition to functions in this
363 section, there are a few others like @code{sprintf} (@pxref{Formatted
364 Output Functions}) and @code{scanf} (@pxref{Formatted Input
365 Functions}).
366
367 @comment string.h
368 @comment ISO
369 @deftypefun {void *} memcpy (void *restrict @var{to}, const void *restrict @var{from}, size_t @var{size})
370 The @code{memcpy} function copies @var{size} bytes from the object
371 beginning at @var{from} into the object beginning at @var{to}. The
372 behavior of this function is undefined if the two arrays @var{to} and
373 @var{from} overlap; use @code{memmove} instead if overlapping is possible.
374
375 The value returned by @code{memcpy} is the value of @var{to}.
376
377 Here is an example of how you might use @code{memcpy} to copy the
378 contents of an array:
379
380 @smallexample
381 struct foo *oldarray, *newarray;
382 int arraysize;
383 @dots{}
384 memcpy (new, old, arraysize * sizeof (struct foo));
385 @end smallexample
386 @end deftypefun
387
388 @comment wchar.h
389 @comment ISO
390 @deftypefun {wchar_t *} wmemcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
391 The @code{wmemcpy} function copies @var{size} wide characters from the object
392 beginning at @var{wfrom} into the object beginning at @var{wto}. The
393 behavior of this function is undefined if the two arrays @var{wto} and
394 @var{wfrom} overlap; use @code{wmemmove} instead if overlapping is possible.
395
396 The following is a possible implementation of @code{wmemcpy} but there
397 are more optimizations possible.
398
399 @smallexample
400 wchar_t *
401 wmemcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
402 size_t size)
403 @{
404 return (wchar_t *) memcpy (wto, wfrom, size * sizeof (wchar_t));
405 @}
406 @end smallexample
407
408 The value returned by @code{wmemcpy} is the value of @var{wto}.
409
410 This function was introduced in @w{Amendment 1} to @w{ISO C90}.
411 @end deftypefun
412
413 @comment string.h
414 @comment GNU
415 @deftypefun {void *} mempcpy (void *restrict @var{to}, const void *restrict @var{from}, size_t @var{size})
416 The @code{mempcpy} function is nearly identical to the @code{memcpy}
417 function. It copies @var{size} bytes from the object beginning at
418 @code{from} into the object pointed to by @var{to}. But instead of
419 returning the value of @var{to} it returns a pointer to the byte
420 following the last written byte in the object beginning at @var{to}.
421 I.e., the value is @code{((void *) ((char *) @var{to} + @var{size}))}.
422
423 This function is useful in situations where a number of objects shall be
424 copied to consecutive memory positions.
425
426 @smallexample
427 void *
428 combine (void *o1, size_t s1, void *o2, size_t s2)
429 @{
430 void *result = malloc (s1 + s2);
431 if (result != NULL)
432 mempcpy (mempcpy (result, o1, s1), o2, s2);
433 return result;
434 @}
435 @end smallexample
436
437 This function is a GNU extension.
438 @end deftypefun
439
440 @comment wchar.h
441 @comment GNU
442 @deftypefun {wchar_t *} wmempcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
443 The @code{wmempcpy} function is nearly identical to the @code{wmemcpy}
444 function. It copies @var{size} wide characters from the object
445 beginning at @code{wfrom} into the object pointed to by @var{wto}. But
446 instead of returning the value of @var{wto} it returns a pointer to the
447 wide character following the last written wide character in the object
448 beginning at @var{wto}. I.e., the value is @code{@var{wto} + @var{size}}.
449
450 This function is useful in situations where a number of objects shall be
451 copied to consecutive memory positions.
452
453 The following is a possible implementation of @code{wmemcpy} but there
454 are more optimizations possible.
455
456 @smallexample
457 wchar_t *
458 wmempcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
459 size_t size)
460 @{
461 return (wchar_t *) mempcpy (wto, wfrom, size * sizeof (wchar_t));
462 @}
463 @end smallexample
464
465 This function is a GNU extension.
466 @end deftypefun
467
468 @comment string.h
469 @comment ISO
470 @deftypefun {void *} memmove (void *@var{to}, const void *@var{from}, size_t @var{size})
471 @code{memmove} copies the @var{size} bytes at @var{from} into the
472 @var{size} bytes at @var{to}, even if those two blocks of space
473 overlap. In the case of overlap, @code{memmove} is careful to copy the
474 original values of the bytes in the block at @var{from}, including those
475 bytes which also belong to the block at @var{to}.
476
477 The value returned by @code{memmove} is the value of @var{to}.
478 @end deftypefun
479
480 @comment wchar.h
481 @comment ISO
482 @deftypefun {wchar_t *} wmemmove (wchar *@var{wto}, const wchar_t *@var{wfrom}, size_t @var{size})
483 @code{wmemmove} copies the @var{size} wide characters at @var{wfrom}
484 into the @var{size} wide characters at @var{wto}, even if those two
485 blocks of space overlap. In the case of overlap, @code{memmove} is
486 careful to copy the original values of the wide characters in the block
487 at @var{wfrom}, including those wide characters which also belong to the
488 block at @var{wto}.
489
490 The following is a possible implementation of @code{wmemcpy} but there
491 are more optimizations possible.
492
493 @smallexample
494 wchar_t *
495 wmempcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
496 size_t size)
497 @{
498 return (wchar_t *) mempcpy (wto, wfrom, size * sizeof (wchar_t));
499 @}
500 @end smallexample
501
502 The value returned by @code{wmemmove} is the value of @var{wto}.
503
504 This function is a GNU extension.
505 @end deftypefun
506
507 @comment string.h
508 @comment SVID
509 @deftypefun {void *} memccpy (void *restrict @var{to}, const void *restrict @var{from}, int @var{c}, size_t @var{size})
510 This function copies no more than @var{size} bytes from @var{from} to
511 @var{to}, stopping if a byte matching @var{c} is found. The return
512 value is a pointer into @var{to} one byte past where @var{c} was copied,
513 or a null pointer if no byte matching @var{c} appeared in the first
514 @var{size} bytes of @var{from}.
515 @end deftypefun
516
517 @comment string.h
518 @comment ISO
519 @deftypefun {void *} memset (void *@var{block}, int @var{c}, size_t @var{size})
520 This function copies the value of @var{c} (converted to an
521 @code{unsigned char}) into each of the first @var{size} bytes of the
522 object beginning at @var{block}. It returns the value of @var{block}.
523 @end deftypefun
524
525 @comment wchar.h
526 @comment ISO
527 @deftypefun {wchar_t *} wmemset (wchar_t *@var{block}, wchar_t @var{wc}, size_t @var{size})
528 This function copies the value of @var{wc} into each of the first
529 @var{size} wide characters of the object beginning at @var{block}. It
530 returns the value of @var{block}.
531 @end deftypefun
532
533 @comment string.h
534 @comment ISO
535 @deftypefun {char *} strcpy (char *restrict @var{to}, const char *restrict @var{from})
536 This copies characters from the string @var{from} (up to and including
537 the terminating null character) into the string @var{to}. Like
538 @code{memcpy}, this function has undefined results if the strings
539 overlap. The return value is the value of @var{to}.
540 @end deftypefun
541
542 @comment wchar.h
543 @comment ISO
544 @deftypefun {wchar_t *} wcscpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
545 This copies wide characters from the string @var{wfrom} (up to and
546 including the terminating null wide character) into the string
547 @var{wto}. Like @code{wmemcpy}, this function has undefined results if
548 the strings overlap. The return value is the value of @var{wto}.
549 @end deftypefun
550
551 @comment string.h
552 @comment ISO
553 @deftypefun {char *} strncpy (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
554 This function is similar to @code{strcpy} but always copies exactly
555 @var{size} characters into @var{to}.
556
557 If the length of @var{from} is more than @var{size}, then @code{strncpy}
558 copies just the first @var{size} characters. Note that in this case
559 there is no null terminator written into @var{to}.
560
561 If the length of @var{from} is less than @var{size}, then @code{strncpy}
562 copies all of @var{from}, followed by enough null characters to add up
563 to @var{size} characters in all. This behavior is rarely useful, but it
564 is specified by the @w{ISO C} standard.
565
566 The behavior of @code{strncpy} is undefined if the strings overlap.
567
568 Using @code{strncpy} as opposed to @code{strcpy} is a way to avoid bugs
569 relating to writing past the end of the allocated space for @var{to}.
570 However, it can also make your program much slower in one common case:
571 copying a string which is probably small into a potentially large buffer.
572 In this case, @var{size} may be large, and when it is, @code{strncpy} will
573 waste a considerable amount of time copying null characters.
574 @end deftypefun
575
576 @comment wchar.h
577 @comment ISO
578 @deftypefun {wchar_t *} wcsncpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
579 This function is similar to @code{wcscpy} but always copies exactly
580 @var{size} wide characters into @var{wto}.
581
582 If the length of @var{wfrom} is more than @var{size}, then
583 @code{wcsncpy} copies just the first @var{size} wide characters. Note
584 that in this case there is no null terminator written into @var{wto}.
585
586 If the length of @var{wfrom} is less than @var{size}, then
587 @code{wcsncpy} copies all of @var{wfrom}, followed by enough null wide
588 characters to add up to @var{size} wide characters in all. This
589 behavior is rarely useful, but it is specified by the @w{ISO C}
590 standard.
591
592 The behavior of @code{wcsncpy} is undefined if the strings overlap.
593
594 Using @code{wcsncpy} as opposed to @code{wcscpy} is a way to avoid bugs
595 relating to writing past the end of the allocated space for @var{wto}.
596 However, it can also make your program much slower in one common case:
597 copying a string which is probably small into a potentially large buffer.
598 In this case, @var{size} may be large, and when it is, @code{wcsncpy} will
599 waste a considerable amount of time copying null wide characters.
600 @end deftypefun
601
602 @comment string.h
603 @comment SVID
604 @deftypefun {char *} strdup (const char *@var{s})
605 This function copies the null-terminated string @var{s} into a newly
606 allocated string. The string is allocated using @code{malloc}; see
607 @ref{Unconstrained Allocation}. If @code{malloc} cannot allocate space
608 for the new string, @code{strdup} returns a null pointer. Otherwise it
609 returns a pointer to the new string.
610 @end deftypefun
611
612 @comment wchar.h
613 @comment GNU
614 @deftypefun {wchar_t *} wcsdup (const wchar_t *@var{ws})
615 This function copies the null-terminated wide character string @var{ws}
616 into a newly allocated string. The string is allocated using
617 @code{malloc}; see @ref{Unconstrained Allocation}. If @code{malloc}
618 cannot allocate space for the new string, @code{wcsdup} returns a null
619 pointer. Otherwise it returns a pointer to the new wide character
620 string.
621
622 This function is a GNU extension.
623 @end deftypefun
624
625 @comment string.h
626 @comment GNU
627 @deftypefun {char *} strndup (const char *@var{s}, size_t @var{size})
628 This function is similar to @code{strdup} but always copies at most
629 @var{size} characters into the newly allocated string.
630
631 If the length of @var{s} is more than @var{size}, then @code{strndup}
632 copies just the first @var{size} characters and adds a closing null
633 terminator. Otherwise all characters are copied and the string is
634 terminated.
635
636 This function is different to @code{strncpy} in that it always
637 terminates the destination string.
638
639 @code{strndup} is a GNU extension.
640 @end deftypefun
641
642 @comment string.h
643 @comment Unknown origin
644 @deftypefun {char *} stpcpy (char *restrict @var{to}, const char *restrict @var{from})
645 This function is like @code{strcpy}, except that it returns a pointer to
646 the end of the string @var{to} (that is, the address of the terminating
647 null character @code{to + strlen (from)}) rather than the beginning.
648
649 For example, this program uses @code{stpcpy} to concatenate @samp{foo}
650 and @samp{bar} to produce @samp{foobar}, which it then prints.
651
652 @smallexample
653 @include stpcpy.c.texi
654 @end smallexample
655
656 This function is not part of the ISO or POSIX standards, and is not
657 customary on Unix systems, but we did not invent it either. Perhaps it
658 comes from MS-DOG.
659
660 Its behavior is undefined if the strings overlap. The function is
661 declared in @file{string.h}.
662 @end deftypefun
663
664 @comment wchar.h
665 @comment GNU
666 @deftypefun {wchar_t *} wcpcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
667 This function is like @code{wcscpy}, except that it returns a pointer to
668 the end of the string @var{wto} (that is, the address of the terminating
669 null character @code{wto + strlen (wfrom)}) rather than the beginning.
670
671 This function is not part of ISO or POSIX but was found useful while
672 developing @theglibc{} itself.
673
674 The behavior of @code{wcpcpy} is undefined if the strings overlap.
675
676 @code{wcpcpy} is a GNU extension and is declared in @file{wchar.h}.
677 @end deftypefun
678
679 @comment string.h
680 @comment GNU
681 @deftypefun {char *} stpncpy (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
682 This function is similar to @code{stpcpy} but copies always exactly
683 @var{size} characters into @var{to}.
684
685 If the length of @var{from} is more then @var{size}, then @code{stpncpy}
686 copies just the first @var{size} characters and returns a pointer to the
687 character directly following the one which was copied last. Note that in
688 this case there is no null terminator written into @var{to}.
689
690 If the length of @var{from} is less than @var{size}, then @code{stpncpy}
691 copies all of @var{from}, followed by enough null characters to add up
692 to @var{size} characters in all. This behavior is rarely useful, but it
693 is implemented to be useful in contexts where this behavior of the
694 @code{strncpy} is used. @code{stpncpy} returns a pointer to the
695 @emph{first} written null character.
696
697 This function is not part of ISO or POSIX but was found useful while
698 developing @theglibc{} itself.
699
700 Its behavior is undefined if the strings overlap. The function is
701 declared in @file{string.h}.
702 @end deftypefun
703
704 @comment wchar.h
705 @comment GNU
706 @deftypefun {wchar_t *} wcpncpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
707 This function is similar to @code{wcpcpy} but copies always exactly
708 @var{wsize} characters into @var{wto}.
709
710 If the length of @var{wfrom} is more then @var{size}, then
711 @code{wcpncpy} copies just the first @var{size} wide characters and
712 returns a pointer to the wide character directly following the last
713 non-null wide character which was copied last. Note that in this case
714 there is no null terminator written into @var{wto}.
715
716 If the length of @var{wfrom} is less than @var{size}, then @code{wcpncpy}
717 copies all of @var{wfrom}, followed by enough null characters to add up
718 to @var{size} characters in all. This behavior is rarely useful, but it
719 is implemented to be useful in contexts where this behavior of the
720 @code{wcsncpy} is used. @code{wcpncpy} returns a pointer to the
721 @emph{first} written null character.
722
723 This function is not part of ISO or POSIX but was found useful while
724 developing @theglibc{} itself.
725
726 Its behavior is undefined if the strings overlap.
727
728 @code{wcpncpy} is a GNU extension and is declared in @file{wchar.h}.
729 @end deftypefun
730
731 @comment string.h
732 @comment GNU
733 @deftypefn {Macro} {char *} strdupa (const char *@var{s})
734 This macro is similar to @code{strdup} but allocates the new string
735 using @code{alloca} instead of @code{malloc} (@pxref{Variable Size
736 Automatic}). This means of course the returned string has the same
737 limitations as any block of memory allocated using @code{alloca}.
738
739 For obvious reasons @code{strdupa} is implemented only as a macro;
740 you cannot get the address of this function. Despite this limitation
741 it is a useful function. The following code shows a situation where
742 using @code{malloc} would be a lot more expensive.
743
744 @smallexample
745 @include strdupa.c.texi
746 @end smallexample
747
748 Please note that calling @code{strtok} using @var{path} directly is
749 invalid. It is also not allowed to call @code{strdupa} in the argument
750 list of @code{strtok} since @code{strdupa} uses @code{alloca}
751 (@pxref{Variable Size Automatic}) can interfere with the parameter
752 passing.
753
754 This function is only available if GNU CC is used.
755 @end deftypefn
756
757 @comment string.h
758 @comment GNU
759 @deftypefn {Macro} {char *} strndupa (const char *@var{s}, size_t @var{size})
760 This function is similar to @code{strndup} but like @code{strdupa} it
761 allocates the new string using @code{alloca}
762 @pxref{Variable Size Automatic}. The same advantages and limitations
763 of @code{strdupa} are valid for @code{strndupa}, too.
764
765 This function is implemented only as a macro, just like @code{strdupa}.
766 Just as @code{strdupa} this macro also must not be used inside the
767 parameter list in a function call.
768
769 @code{strndupa} is only available if GNU CC is used.
770 @end deftypefn
771
772 @comment string.h
773 @comment ISO
774 @deftypefun {char *} strcat (char *restrict @var{to}, const char *restrict @var{from})
775 The @code{strcat} function is similar to @code{strcpy}, except that the
776 characters from @var{from} are concatenated or appended to the end of
777 @var{to}, instead of overwriting it. That is, the first character from
778 @var{from} overwrites the null character marking the end of @var{to}.
779
780 An equivalent definition for @code{strcat} would be:
781
782 @smallexample
783 char *
784 strcat (char *restrict to, const char *restrict from)
785 @{
786 strcpy (to + strlen (to), from);
787 return to;
788 @}
789 @end smallexample
790
791 This function has undefined results if the strings overlap.
792 @end deftypefun
793
794 @comment wchar.h
795 @comment ISO
796 @deftypefun {wchar_t *} wcscat (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
797 The @code{wcscat} function is similar to @code{wcscpy}, except that the
798 characters from @var{wfrom} are concatenated or appended to the end of
799 @var{wto}, instead of overwriting it. That is, the first character from
800 @var{wfrom} overwrites the null character marking the end of @var{wto}.
801
802 An equivalent definition for @code{wcscat} would be:
803
804 @smallexample
805 wchar_t *
806 wcscat (wchar_t *wto, const wchar_t *wfrom)
807 @{
808 wcscpy (wto + wcslen (wto), wfrom);
809 return wto;
810 @}
811 @end smallexample
812
813 This function has undefined results if the strings overlap.
814 @end deftypefun
815
816 Programmers using the @code{strcat} or @code{wcscat} function (or the
817 following @code{strncat} or @code{wcsncar} functions for that matter)
818 can easily be recognized as lazy and reckless. In almost all situations
819 the lengths of the participating strings are known (it better should be
820 since how can one otherwise ensure the allocated size of the buffer is
821 sufficient?) Or at least, one could know them if one keeps track of the
822 results of the various function calls. But then it is very inefficient
823 to use @code{strcat}/@code{wcscat}. A lot of time is wasted finding the
824 end of the destination string so that the actual copying can start.
825 This is a common example:
826
827 @cindex __va_copy
828 @cindex va_copy
829 @smallexample
830 /* @r{This function concatenates arbitrarily many strings. The last}
831 @r{parameter must be @code{NULL}.} */
832 char *
833 concat (const char *str, @dots{})
834 @{
835 va_list ap, ap2;
836 size_t total = 1;
837 const char *s;
838 char *result;
839
840 va_start (ap, str);
841 /* @r{Actually @code{va_copy}, but this is the name more gcc versions}
842 @r{understand.} */
843 __va_copy (ap2, ap);
844
845 /* @r{Determine how much space we need.} */
846 for (s = str; s != NULL; s = va_arg (ap, const char *))
847 total += strlen (s);
848
849 va_end (ap);
850
851 result = (char *) malloc (total);
852 if (result != NULL)
853 @{
854 result[0] = '\0';
855
856 /* @r{Copy the strings.} */
857 for (s = str; s != NULL; s = va_arg (ap2, const char *))
858 strcat (result, s);
859 @}
860
861 va_end (ap2);
862
863 return result;
864 @}
865 @end smallexample
866
867 This looks quite simple, especially the second loop where the strings
868 are actually copied. But these innocent lines hide a major performance
869 penalty. Just imagine that ten strings of 100 bytes each have to be
870 concatenated. For the second string we search the already stored 100
871 bytes for the end of the string so that we can append the next string.
872 For all strings in total the comparisons necessary to find the end of
873 the intermediate results sums up to 5500! If we combine the copying
874 with the search for the allocation we can write this function more
875 efficient:
876
877 @smallexample
878 char *
879 concat (const char *str, @dots{})
880 @{
881 va_list ap;
882 size_t allocated = 100;
883 char *result = (char *) malloc (allocated);
884
885 if (result != NULL)
886 @{
887 char *newp;
888 char *wp;
889 const char *s;
890
891 va_start (ap, str);
892
893 wp = result;
894 for (s = str; s != NULL; s = va_arg (ap, const char *))
895 @{
896 size_t len = strlen (s);
897
898 /* @r{Resize the allocated memory if necessary.} */
899 if (wp + len + 1 > result + allocated)
900 @{
901 allocated = (allocated + len) * 2;
902 newp = (char *) realloc (result, allocated);
903 if (newp == NULL)
904 @{
905 free (result);
906 return NULL;
907 @}
908 wp = newp + (wp - result);
909 result = newp;
910 @}
911
912 wp = mempcpy (wp, s, len);
913 @}
914
915 /* @r{Terminate the result string.} */
916 *wp++ = '\0';
917
918 /* @r{Resize memory to the optimal size.} */
919 newp = realloc (result, wp - result);
920 if (newp != NULL)
921 result = newp;
922
923 va_end (ap);
924 @}
925
926 return result;
927 @}
928 @end smallexample
929
930 With a bit more knowledge about the input strings one could fine-tune
931 the memory allocation. The difference we are pointing to here is that
932 we don't use @code{strcat} anymore. We always keep track of the length
933 of the current intermediate result so we can safe us the search for the
934 end of the string and use @code{mempcpy}. Please note that we also
935 don't use @code{stpcpy} which might seem more natural since we handle
936 with strings. But this is not necessary since we already know the
937 length of the string and therefore can use the faster memory copying
938 function. The example would work for wide characters the same way.
939
940 Whenever a programmer feels the need to use @code{strcat} she or he
941 should think twice and look through the program whether the code cannot
942 be rewritten to take advantage of already calculated results. Again: it
943 is almost always unnecessary to use @code{strcat}.
944
945 @comment string.h
946 @comment ISO
947 @deftypefun {char *} strncat (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
948 This function is like @code{strcat} except that not more than @var{size}
949 characters from @var{from} are appended to the end of @var{to}. A
950 single null character is also always appended to @var{to}, so the total
951 allocated size of @var{to} must be at least @code{@var{size} + 1} bytes
952 longer than its initial length.
953
954 The @code{strncat} function could be implemented like this:
955
956 @smallexample
957 @group
958 char *
959 strncat (char *to, const char *from, size_t size)
960 @{
961 to[strlen (to) + size] = '\0';
962 strncpy (to + strlen (to), from, size);
963 return to;
964 @}
965 @end group
966 @end smallexample
967
968 The behavior of @code{strncat} is undefined if the strings overlap.
969 @end deftypefun
970
971 @comment wchar.h
972 @comment ISO
973 @deftypefun {wchar_t *} wcsncat (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
974 This function is like @code{wcscat} except that not more than @var{size}
975 characters from @var{from} are appended to the end of @var{to}. A
976 single null character is also always appended to @var{to}, so the total
977 allocated size of @var{to} must be at least @code{@var{size} + 1} bytes
978 longer than its initial length.
979
980 The @code{wcsncat} function could be implemented like this:
981
982 @smallexample
983 @group
984 wchar_t *
985 wcsncat (wchar_t *restrict wto, const wchar_t *restrict wfrom,
986 size_t size)
987 @{
988 wto[wcslen (to) + size] = L'\0';
989 wcsncpy (wto + wcslen (wto), wfrom, size);
990 return wto;
991 @}
992 @end group
993 @end smallexample
994
995 The behavior of @code{wcsncat} is undefined if the strings overlap.
996 @end deftypefun
997
998 Here is an example showing the use of @code{strncpy} and @code{strncat}
999 (the wide character version is equivalent). Notice how, in the call to
1000 @code{strncat}, the @var{size} parameter is computed to avoid
1001 overflowing the character array @code{buffer}.
1002
1003 @smallexample
1004 @include strncat.c.texi
1005 @end smallexample
1006
1007 @noindent
1008 The output produced by this program looks like:
1009
1010 @smallexample
1011 hello
1012 hello, wo
1013 @end smallexample
1014
1015 @comment string.h
1016 @comment BSD
1017 @deftypefun void bcopy (const void *@var{from}, void *@var{to}, size_t @var{size})
1018 This is a partially obsolete alternative for @code{memmove}, derived from
1019 BSD. Note that it is not quite equivalent to @code{memmove}, because the
1020 arguments are not in the same order and there is no return value.
1021 @end deftypefun
1022
1023 @comment string.h
1024 @comment BSD
1025 @deftypefun void bzero (void *@var{block}, size_t @var{size})
1026 This is a partially obsolete alternative for @code{memset}, derived from
1027 BSD. Note that it is not as general as @code{memset}, because the only
1028 value it can store is zero.
1029 @end deftypefun
1030
1031 @node String/Array Comparison
1032 @section String/Array Comparison
1033 @cindex comparing strings and arrays
1034 @cindex string comparison functions
1035 @cindex array comparison functions
1036 @cindex predicates on strings
1037 @cindex predicates on arrays
1038
1039 You can use the functions in this section to perform comparisons on the
1040 contents of strings and arrays. As well as checking for equality, these
1041 functions can also be used as the ordering functions for sorting
1042 operations. @xref{Searching and Sorting}, for an example of this.
1043
1044 Unlike most comparison operations in C, the string comparison functions
1045 return a nonzero value if the strings are @emph{not} equivalent rather
1046 than if they are. The sign of the value indicates the relative ordering
1047 of the first characters in the strings that are not equivalent: a
1048 negative value indicates that the first string is ``less'' than the
1049 second, while a positive value indicates that the first string is
1050 ``greater''.
1051
1052 The most common use of these functions is to check only for equality.
1053 This is canonically done with an expression like @w{@samp{! strcmp (s1, s2)}}.
1054
1055 All of these functions are declared in the header file @file{string.h}.
1056 @pindex string.h
1057
1058 @comment string.h
1059 @comment ISO
1060 @deftypefun int memcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
1061 The function @code{memcmp} compares the @var{size} bytes of memory
1062 beginning at @var{a1} against the @var{size} bytes of memory beginning
1063 at @var{a2}. The value returned has the same sign as the difference
1064 between the first differing pair of bytes (interpreted as @code{unsigned
1065 char} objects, then promoted to @code{int}).
1066
1067 If the contents of the two blocks are equal, @code{memcmp} returns
1068 @code{0}.
1069 @end deftypefun
1070
1071 @comment wcjar.h
1072 @comment ISO
1073 @deftypefun int wmemcmp (const wchar_t *@var{a1}, const wchar_t *@var{a2}, size_t @var{size})
1074 The function @code{wmemcmp} compares the @var{size} wide characters
1075 beginning at @var{a1} against the @var{size} wide characters beginning
1076 at @var{a2}. The value returned is smaller than or larger than zero
1077 depending on whether the first differing wide character is @var{a1} is
1078 smaller or larger than the corresponding character in @var{a2}.
1079
1080 If the contents of the two blocks are equal, @code{wmemcmp} returns
1081 @code{0}.
1082 @end deftypefun
1083
1084 On arbitrary arrays, the @code{memcmp} function is mostly useful for
1085 testing equality. It usually isn't meaningful to do byte-wise ordering
1086 comparisons on arrays of things other than bytes. For example, a
1087 byte-wise comparison on the bytes that make up floating-point numbers
1088 isn't likely to tell you anything about the relationship between the
1089 values of the floating-point numbers.
1090
1091 @code{wmemcmp} is really only useful to compare arrays of type
1092 @code{wchar_t} since the function looks at @code{sizeof (wchar_t)} bytes
1093 at a time and this number of bytes is system dependent.
1094
1095 You should also be careful about using @code{memcmp} to compare objects
1096 that can contain ``holes'', such as the padding inserted into structure
1097 objects to enforce alignment requirements, extra space at the end of
1098 unions, and extra characters at the ends of strings whose length is less
1099 than their allocated size. The contents of these ``holes'' are
1100 indeterminate and may cause strange behavior when performing byte-wise
1101 comparisons. For more predictable results, perform an explicit
1102 component-wise comparison.
1103
1104 For example, given a structure type definition like:
1105
1106 @smallexample
1107 struct foo
1108 @{
1109 unsigned char tag;
1110 union
1111 @{
1112 double f;
1113 long i;
1114 char *p;
1115 @} value;
1116 @};
1117 @end smallexample
1118
1119 @noindent
1120 you are better off writing a specialized comparison function to compare
1121 @code{struct foo} objects instead of comparing them with @code{memcmp}.
1122
1123 @comment string.h
1124 @comment ISO
1125 @deftypefun int strcmp (const char *@var{s1}, const char *@var{s2})
1126 The @code{strcmp} function compares the string @var{s1} against
1127 @var{s2}, returning a value that has the same sign as the difference
1128 between the first differing pair of characters (interpreted as
1129 @code{unsigned char} objects, then promoted to @code{int}).
1130
1131 If the two strings are equal, @code{strcmp} returns @code{0}.
1132
1133 A consequence of the ordering used by @code{strcmp} is that if @var{s1}
1134 is an initial substring of @var{s2}, then @var{s1} is considered to be
1135 ``less than'' @var{s2}.
1136
1137 @code{strcmp} does not take sorting conventions of the language the
1138 strings are written in into account. To get that one has to use
1139 @code{strcoll}.
1140 @end deftypefun
1141
1142 @comment wchar.h
1143 @comment ISO
1144 @deftypefun int wcscmp (const wchar_t *@var{ws1}, const wchar_t *@var{ws2})
1145
1146 The @code{wcscmp} function compares the wide character string @var{ws1}
1147 against @var{ws2}. The value returned is smaller than or larger than zero
1148 depending on whether the first differing wide character is @var{ws1} is
1149 smaller or larger than the corresponding character in @var{ws2}.
1150
1151 If the two strings are equal, @code{wcscmp} returns @code{0}.
1152
1153 A consequence of the ordering used by @code{wcscmp} is that if @var{ws1}
1154 is an initial substring of @var{ws2}, then @var{ws1} is considered to be
1155 ``less than'' @var{ws2}.
1156
1157 @code{wcscmp} does not take sorting conventions of the language the
1158 strings are written in into account. To get that one has to use
1159 @code{wcscoll}.
1160 @end deftypefun
1161
1162 @comment string.h
1163 @comment BSD
1164 @deftypefun int strcasecmp (const char *@var{s1}, const char *@var{s2})
1165 This function is like @code{strcmp}, except that differences in case are
1166 ignored. How uppercase and lowercase characters are related is
1167 determined by the currently selected locale. In the standard @code{"C"}
1168 locale the characters @"A and @"a do not match but in a locale which
1169 regards these characters as parts of the alphabet they do match.
1170
1171 @noindent
1172 @code{strcasecmp} is derived from BSD.
1173 @end deftypefun
1174
1175 @comment wchar.h
1176 @comment GNU
1177 @deftypefun int wcscasecmp (const wchar_t *@var{ws1}, const wchar_T *@var{ws2})
1178 This function is like @code{wcscmp}, except that differences in case are
1179 ignored. How uppercase and lowercase characters are related is
1180 determined by the currently selected locale. In the standard @code{"C"}
1181 locale the characters @"A and @"a do not match but in a locale which
1182 regards these characters as parts of the alphabet they do match.
1183
1184 @noindent
1185 @code{wcscasecmp} is a GNU extension.
1186 @end deftypefun
1187
1188 @comment string.h
1189 @comment ISO
1190 @deftypefun int strncmp (const char *@var{s1}, const char *@var{s2}, size_t @var{size})
1191 This function is the similar to @code{strcmp}, except that no more than
1192 @var{size} characters are compared. In other words, if the two
1193 strings are the same in their first @var{size} characters, the
1194 return value is zero.
1195 @end deftypefun
1196
1197 @comment wchar.h
1198 @comment ISO
1199 @deftypefun int wcsncmp (const wchar_t *@var{ws1}, const wchar_t *@var{ws2}, size_t @var{size})
1200 This function is the similar to @code{wcscmp}, except that no more than
1201 @var{size} wide characters are compared. In other words, if the two
1202 strings are the same in their first @var{size} wide characters, the
1203 return value is zero.
1204 @end deftypefun
1205
1206 @comment string.h
1207 @comment BSD
1208 @deftypefun int strncasecmp (const char *@var{s1}, const char *@var{s2}, size_t @var{n})
1209 This function is like @code{strncmp}, except that differences in case
1210 are ignored. Like @code{strcasecmp}, it is locale dependent how
1211 uppercase and lowercase characters are related.
1212
1213 @noindent
1214 @code{strncasecmp} is a GNU extension.
1215 @end deftypefun
1216
1217 @comment wchar.h
1218 @comment GNU
1219 @deftypefun int wcsncasecmp (const wchar_t *@var{ws1}, const wchar_t *@var{s2}, size_t @var{n})
1220 This function is like @code{wcsncmp}, except that differences in case
1221 are ignored. Like @code{wcscasecmp}, it is locale dependent how
1222 uppercase and lowercase characters are related.
1223
1224 @noindent
1225 @code{wcsncasecmp} is a GNU extension.
1226 @end deftypefun
1227
1228 Here are some examples showing the use of @code{strcmp} and
1229 @code{strncmp} (equivalent examples can be constructed for the wide
1230 character functions). These examples assume the use of the ASCII
1231 character set. (If some other character set---say, EBCDIC---is used
1232 instead, then the glyphs are associated with different numeric codes,
1233 and the return values and ordering may differ.)
1234
1235 @smallexample
1236 strcmp ("hello", "hello")
1237 @result{} 0 /* @r{These two strings are the same.} */
1238 strcmp ("hello", "Hello")
1239 @result{} 32 /* @r{Comparisons are case-sensitive.} */
1240 strcmp ("hello", "world")
1241 @result{} -15 /* @r{The character @code{'h'} comes before @code{'w'}.} */
1242 strcmp ("hello", "hello, world")
1243 @result{} -44 /* @r{Comparing a null character against a comma.} */
1244 strncmp ("hello", "hello, world", 5)
1245 @result{} 0 /* @r{The initial 5 characters are the same.} */
1246 strncmp ("hello, world", "hello, stupid world!!!", 5)
1247 @result{} 0 /* @r{The initial 5 characters are the same.} */
1248 @end smallexample
1249
1250 @comment string.h
1251 @comment GNU
1252 @deftypefun int strverscmp (const char *@var{s1}, const char *@var{s2})
1253 The @code{strverscmp} function compares the string @var{s1} against
1254 @var{s2}, considering them as holding indices/version numbers. The
1255 return value follows the same conventions as found in the
1256 @code{strcmp} function. In fact, if @var{s1} and @var{s2} contain no
1257 digits, @code{strverscmp} behaves like @code{strcmp}.
1258
1259 Basically, we compare strings normally (character by character), until
1260 we find a digit in each string - then we enter a special comparison
1261 mode, where each sequence of digits is taken as a whole. If we reach the
1262 end of these two parts without noticing a difference, we return to the
1263 standard comparison mode. There are two types of numeric parts:
1264 "integral" and "fractional" (those begin with a '0'). The types
1265 of the numeric parts affect the way we sort them:
1266
1267 @itemize @bullet
1268 @item
1269 integral/integral: we compare values as you would expect.
1270
1271 @item
1272 fractional/integral: the fractional part is less than the integral one.
1273 Again, no surprise.
1274
1275 @item
1276 fractional/fractional: the things become a bit more complex.
1277 If the common prefix contains only leading zeroes, the longest part is less
1278 than the other one; else the comparison behaves normally.
1279 @end itemize
1280
1281 @smallexample
1282 strverscmp ("no digit", "no digit")
1283 @result{} 0 /* @r{same behavior as strcmp.} */
1284 strverscmp ("item#99", "item#100")
1285 @result{} <0 /* @r{same prefix, but 99 < 100.} */
1286 strverscmp ("alpha1", "alpha001")
1287 @result{} >0 /* @r{fractional part inferior to integral one.} */
1288 strverscmp ("part1_f012", "part1_f01")
1289 @result{} >0 /* @r{two fractional parts.} */
1290 strverscmp ("foo.009", "foo.0")
1291 @result{} <0 /* @r{idem, but with leading zeroes only.} */
1292 @end smallexample
1293
1294 This function is especially useful when dealing with filename sorting,
1295 because filenames frequently hold indices/version numbers.
1296
1297 @code{strverscmp} is a GNU extension.
1298 @end deftypefun
1299
1300 @comment string.h
1301 @comment BSD
1302 @deftypefun int bcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
1303 This is an obsolete alias for @code{memcmp}, derived from BSD.
1304 @end deftypefun
1305
1306 @node Collation Functions
1307 @section Collation Functions
1308
1309 @cindex collating strings
1310 @cindex string collation functions
1311
1312 In some locales, the conventions for lexicographic ordering differ from
1313 the strict numeric ordering of character codes. For example, in Spanish
1314 most glyphs with diacritical marks such as accents are not considered
1315 distinct letters for the purposes of collation. On the other hand, the
1316 two-character sequence @samp{ll} is treated as a single letter that is
1317 collated immediately after @samp{l}.
1318
1319 You can use the functions @code{strcoll} and @code{strxfrm} (declared in
1320 the headers file @file{string.h}) and @code{wcscoll} and @code{wcsxfrm}
1321 (declared in the headers file @file{wchar}) to compare strings using a
1322 collation ordering appropriate for the current locale. The locale used
1323 by these functions in particular can be specified by setting the locale
1324 for the @code{LC_COLLATE} category; see @ref{Locales}.
1325 @pindex string.h
1326 @pindex wchar.h
1327
1328 In the standard C locale, the collation sequence for @code{strcoll} is
1329 the same as that for @code{strcmp}. Similarly, @code{wcscoll} and
1330 @code{wcscmp} are the same in this situation.
1331
1332 Effectively, the way these functions work is by applying a mapping to
1333 transform the characters in a string to a byte sequence that represents
1334 the string's position in the collating sequence of the current locale.
1335 Comparing two such byte sequences in a simple fashion is equivalent to
1336 comparing the strings with the locale's collating sequence.
1337
1338 The functions @code{strcoll} and @code{wcscoll} perform this translation
1339 implicitly, in order to do one comparison. By contrast, @code{strxfrm}
1340 and @code{wcsxfrm} perform the mapping explicitly. If you are making
1341 multiple comparisons using the same string or set of strings, it is
1342 likely to be more efficient to use @code{strxfrm} or @code{wcsxfrm} to
1343 transform all the strings just once, and subsequently compare the
1344 transformed strings with @code{strcmp} or @code{wcscmp}.
1345
1346 @comment string.h
1347 @comment ISO
1348 @deftypefun int strcoll (const char *@var{s1}, const char *@var{s2})
1349 The @code{strcoll} function is similar to @code{strcmp} but uses the
1350 collating sequence of the current locale for collation (the
1351 @code{LC_COLLATE} locale).
1352 @end deftypefun
1353
1354 @comment wchar.h
1355 @comment ISO
1356 @deftypefun int wcscoll (const wchar_t *@var{ws1}, const wchar_t *@var{ws2})
1357 The @code{wcscoll} function is similar to @code{wcscmp} but uses the
1358 collating sequence of the current locale for collation (the
1359 @code{LC_COLLATE} locale).
1360 @end deftypefun
1361
1362 Here is an example of sorting an array of strings, using @code{strcoll}
1363 to compare them. The actual sort algorithm is not written here; it
1364 comes from @code{qsort} (@pxref{Array Sort Function}). The job of the
1365 code shown here is to say how to compare the strings while sorting them.
1366 (Later on in this section, we will show a way to do this more
1367 efficiently using @code{strxfrm}.)
1368
1369 @smallexample
1370 /* @r{This is the comparison function used with @code{qsort}.} */
1371
1372 int
1373 compare_elements (const void *v1, const void *v2)
1374 @{
1375 char * const *p1 = v1;
1376 char * const *p1 = v2;
1377
1378 return strcoll (*p1, *p2);
1379 @}
1380
1381 /* @r{This is the entry point---the function to sort}
1382 @r{strings using the locale's collating sequence.} */
1383
1384 void
1385 sort_strings (char **array, int nstrings)
1386 @{
1387 /* @r{Sort @code{temp_array} by comparing the strings.} */
1388 qsort (array, nstrings,
1389 sizeof (char *), compare_elements);
1390 @}
1391 @end smallexample
1392
1393 @cindex converting string to collation order
1394 @comment string.h
1395 @comment ISO
1396 @deftypefun size_t strxfrm (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
1397 The function @code{strxfrm} transforms the string @var{from} using the
1398 collation transformation determined by the locale currently selected for
1399 collation, and stores the transformed string in the array @var{to}. Up
1400 to @var{size} characters (including a terminating null character) are
1401 stored.
1402
1403 The behavior is undefined if the strings @var{to} and @var{from}
1404 overlap; see @ref{Copying and Concatenation}.
1405
1406 The return value is the length of the entire transformed string. This
1407 value is not affected by the value of @var{size}, but if it is greater
1408 or equal than @var{size}, it means that the transformed string did not
1409 entirely fit in the array @var{to}. In this case, only as much of the
1410 string as actually fits was stored. To get the whole transformed
1411 string, call @code{strxfrm} again with a bigger output array.
1412
1413 The transformed string may be longer than the original string, and it
1414 may also be shorter.
1415
1416 If @var{size} is zero, no characters are stored in @var{to}. In this
1417 case, @code{strxfrm} simply returns the number of characters that would
1418 be the length of the transformed string. This is useful for determining
1419 what size the allocated array should be. It does not matter what
1420 @var{to} is if @var{size} is zero; @var{to} may even be a null pointer.
1421 @end deftypefun
1422
1423 @comment wchar.h
1424 @comment ISO
1425 @deftypefun size_t wcsxfrm (wchar_t *restrict @var{wto}, const wchar_t *@var{wfrom}, size_t @var{size})
1426 The function @code{wcsxfrm} transforms wide character string @var{wfrom}
1427 using the collation transformation determined by the locale currently
1428 selected for collation, and stores the transformed string in the array
1429 @var{wto}. Up to @var{size} wide characters (including a terminating null
1430 character) are stored.
1431
1432 The behavior is undefined if the strings @var{wto} and @var{wfrom}
1433 overlap; see @ref{Copying and Concatenation}.
1434
1435 The return value is the length of the entire transformed wide character
1436 string. This value is not affected by the value of @var{size}, but if
1437 it is greater or equal than @var{size}, it means that the transformed
1438 wide character string did not entirely fit in the array @var{wto}. In
1439 this case, only as much of the wide character string as actually fits
1440 was stored. To get the whole transformed wide character string, call
1441 @code{wcsxfrm} again with a bigger output array.
1442
1443 The transformed wide character string may be longer than the original
1444 wide character string, and it may also be shorter.
1445
1446 If @var{size} is zero, no characters are stored in @var{to}. In this
1447 case, @code{wcsxfrm} simply returns the number of wide characters that
1448 would be the length of the transformed wide character string. This is
1449 useful for determining what size the allocated array should be (remember
1450 to multiply with @code{sizeof (wchar_t)}). It does not matter what
1451 @var{wto} is if @var{size} is zero; @var{wto} may even be a null pointer.
1452 @end deftypefun
1453
1454 Here is an example of how you can use @code{strxfrm} when
1455 you plan to do many comparisons. It does the same thing as the previous
1456 example, but much faster, because it has to transform each string only
1457 once, no matter how many times it is compared with other strings. Even
1458 the time needed to allocate and free storage is much less than the time
1459 we save, when there are many strings.
1460
1461 @smallexample
1462 struct sorter @{ char *input; char *transformed; @};
1463
1464 /* @r{This is the comparison function used with @code{qsort}}
1465 @r{to sort an array of @code{struct sorter}.} */
1466
1467 int
1468 compare_elements (const void *v1, const void *v2)
1469 @{
1470 const struct sorter *p1 = v1;
1471 const struct sorter *p2 = v2;
1472
1473 return strcmp (p1->transformed, p2->transformed);
1474 @}
1475
1476 /* @r{This is the entry point---the function to sort}
1477 @r{strings using the locale's collating sequence.} */
1478
1479 void
1480 sort_strings_fast (char **array, int nstrings)
1481 @{
1482 struct sorter temp_array[nstrings];
1483 int i;
1484
1485 /* @r{Set up @code{temp_array}. Each element contains}
1486 @r{one input string and its transformed string.} */
1487 for (i = 0; i < nstrings; i++)
1488 @{
1489 size_t length = strlen (array[i]) * 2;
1490 char *transformed;
1491 size_t transformed_length;
1492
1493 temp_array[i].input = array[i];
1494
1495 /* @r{First try a buffer perhaps big enough.} */
1496 transformed = (char *) xmalloc (length);
1497
1498 /* @r{Transform @code{array[i]}.} */
1499 transformed_length = strxfrm (transformed, array[i], length);
1500
1501 /* @r{If the buffer was not large enough, resize it}
1502 @r{and try again.} */
1503 if (transformed_length >= length)
1504 @{
1505 /* @r{Allocate the needed space. +1 for terminating}
1506 @r{@code{NUL} character.} */
1507 transformed = (char *) xrealloc (transformed,
1508 transformed_length + 1);
1509
1510 /* @r{The return value is not interesting because we know}
1511 @r{how long the transformed string is.} */
1512 (void) strxfrm (transformed, array[i],
1513 transformed_length + 1);
1514 @}
1515
1516 temp_array[i].transformed = transformed;
1517 @}
1518
1519 /* @r{Sort @code{temp_array} by comparing transformed strings.} */
1520 qsort (temp_array, sizeof (struct sorter),
1521 nstrings, compare_elements);
1522
1523 /* @r{Put the elements back in the permanent array}
1524 @r{in their sorted order.} */
1525 for (i = 0; i < nstrings; i++)
1526 array[i] = temp_array[i].input;
1527
1528 /* @r{Free the strings we allocated.} */
1529 for (i = 0; i < nstrings; i++)
1530 free (temp_array[i].transformed);
1531 @}
1532 @end smallexample
1533
1534 The interesting part of this code for the wide character version would
1535 look like this:
1536
1537 @smallexample
1538 void
1539 sort_strings_fast (wchar_t **array, int nstrings)
1540 @{
1541 @dots{}
1542 /* @r{Transform @code{array[i]}.} */
1543 transformed_length = wcsxfrm (transformed, array[i], length);
1544
1545 /* @r{If the buffer was not large enough, resize it}
1546 @r{and try again.} */
1547 if (transformed_length >= length)
1548 @{
1549 /* @r{Allocate the needed space. +1 for terminating}
1550 @r{@code{NUL} character.} */
1551 transformed = (wchar_t *) xrealloc (transformed,
1552 (transformed_length + 1)
1553 * sizeof (wchar_t));
1554
1555 /* @r{The return value is not interesting because we know}
1556 @r{how long the transformed string is.} */
1557 (void) wcsxfrm (transformed, array[i],
1558 transformed_length + 1);
1559 @}
1560 @dots{}
1561 @end smallexample
1562
1563 @noindent
1564 Note the additional multiplication with @code{sizeof (wchar_t)} in the
1565 @code{realloc} call.
1566
1567 @strong{Compatibility Note:} The string collation functions are a new
1568 feature of @w{ISO C90}. Older C dialects have no equivalent feature.
1569 The wide character versions were introduced in @w{Amendment 1} to @w{ISO
1570 C90}.
1571
1572 @node Search Functions
1573 @section Search Functions
1574
1575 This section describes library functions which perform various kinds
1576 of searching operations on strings and arrays. These functions are
1577 declared in the header file @file{string.h}.
1578 @pindex string.h
1579 @cindex search functions (for strings)
1580 @cindex string search functions
1581
1582 @comment string.h
1583 @comment ISO
1584 @deftypefun {void *} memchr (const void *@var{block}, int @var{c}, size_t @var{size})
1585 This function finds the first occurrence of the byte @var{c} (converted
1586 to an @code{unsigned char}) in the initial @var{size} bytes of the
1587 object beginning at @var{block}. The return value is a pointer to the
1588 located byte, or a null pointer if no match was found.
1589 @end deftypefun
1590
1591 @comment wchar.h
1592 @comment ISO
1593 @deftypefun {wchar_t *} wmemchr (const wchar_t *@var{block}, wchar_t @var{wc}, size_t @var{size})
1594 This function finds the first occurrence of the wide character @var{wc}
1595 in the initial @var{size} wide characters of the object beginning at
1596 @var{block}. The return value is a pointer to the located wide
1597 character, or a null pointer if no match was found.
1598 @end deftypefun
1599
1600 @comment string.h
1601 @comment GNU
1602 @deftypefun {void *} rawmemchr (const void *@var{block}, int @var{c})
1603 Often the @code{memchr} function is used with the knowledge that the
1604 byte @var{c} is available in the memory block specified by the
1605 parameters. But this means that the @var{size} parameter is not really
1606 needed and that the tests performed with it at runtime (to check whether
1607 the end of the block is reached) are not needed.
1608
1609 The @code{rawmemchr} function exists for just this situation which is
1610 surprisingly frequent. The interface is similar to @code{memchr} except
1611 that the @var{size} parameter is missing. The function will look beyond
1612 the end of the block pointed to by @var{block} in case the programmer
1613 made an error in assuming that the byte @var{c} is present in the block.
1614 In this case the result is unspecified. Otherwise the return value is a
1615 pointer to the located byte.
1616
1617 This function is of special interest when looking for the end of a
1618 string. Since all strings are terminated by a null byte a call like
1619
1620 @smallexample
1621 rawmemchr (str, '\0')
1622 @end smallexample
1623
1624 @noindent
1625 will never go beyond the end of the string.
1626
1627 This function is a GNU extension.
1628 @end deftypefun
1629
1630 @comment string.h
1631 @comment GNU
1632 @deftypefun {void *} memrchr (const void *@var{block}, int @var{c}, size_t @var{size})
1633 The function @code{memrchr} is like @code{memchr}, except that it searches
1634 backwards from the end of the block defined by @var{block} and @var{size}
1635 (instead of forwards from the front).
1636
1637 This function is a GNU extension.
1638 @end deftypefun
1639
1640 @comment string.h
1641 @comment ISO
1642 @deftypefun {char *} strchr (const char *@var{string}, int @var{c})
1643 The @code{strchr} function finds the first occurrence of the character
1644 @var{c} (converted to a @code{char}) in the null-terminated string
1645 beginning at @var{string}. The return value is a pointer to the located
1646 character, or a null pointer if no match was found.
1647
1648 For example,
1649 @smallexample
1650 strchr ("hello, world", 'l')
1651 @result{} "llo, world"
1652 strchr ("hello, world", '?')
1653 @result{} NULL
1654 @end smallexample
1655
1656 The terminating null character is considered to be part of the string,
1657 so you can use this function get a pointer to the end of a string by
1658 specifying a null character as the value of the @var{c} argument.
1659
1660 When @code{strchr} returns a null pointer, it does not let you know
1661 the position of the terminating null character it has found. If you
1662 need that information, it is better (but less portable) to use
1663 @code{strchrnul} than to search for it a second time.
1664 @end deftypefun
1665
1666 @comment wchar.h
1667 @comment ISO
1668 @deftypefun {wchar_t *} wcschr (const wchar_t *@var{wstring}, int @var{wc})
1669 The @code{wcschr} function finds the first occurrence of the wide
1670 character @var{wc} in the null-terminated wide character string
1671 beginning at @var{wstring}. The return value is a pointer to the
1672 located wide character, or a null pointer if no match was found.
1673
1674 The terminating null character is considered to be part of the wide
1675 character string, so you can use this function get a pointer to the end
1676 of a wide character string by specifying a null wude character as the
1677 value of the @var{wc} argument. It would be better (but less portable)
1678 to use @code{wcschrnul} in this case, though.
1679 @end deftypefun
1680
1681 @comment string.h
1682 @comment GNU
1683 @deftypefun {char *} strchrnul (const char *@var{string}, int @var{c})
1684 @code{strchrnul} is the same as @code{strchr} except that if it does
1685 not find the character, it returns a pointer to string's terminating
1686 null character rather than a null pointer.
1687
1688 This function is a GNU extension.
1689 @end deftypefun
1690
1691 @comment wchar.h
1692 @comment GNU
1693 @deftypefun {wchar_t *} wcschrnul (const wchar_t *@var{wstring}, wchar_t @var{wc})
1694 @code{wcschrnul} is the same as @code{wcschr} except that if it does not
1695 find the wide character, it returns a pointer to wide character string's
1696 terminating null wide character rather than a null pointer.
1697
1698 This function is a GNU extension.
1699 @end deftypefun
1700
1701 One useful, but unusual, use of the @code{strchr}
1702 function is when one wants to have a pointer pointing to the NUL byte
1703 terminating a string. This is often written in this way:
1704
1705 @smallexample
1706 s += strlen (s);
1707 @end smallexample
1708
1709 @noindent
1710 This is almost optimal but the addition operation duplicated a bit of
1711 the work already done in the @code{strlen} function. A better solution
1712 is this:
1713
1714 @smallexample
1715 s = strchr (s, '\0');
1716 @end smallexample
1717
1718 There is no restriction on the second parameter of @code{strchr} so it
1719 could very well also be the NUL character. Those readers thinking very
1720 hard about this might now point out that the @code{strchr} function is
1721 more expensive than the @code{strlen} function since we have two abort
1722 criteria. This is right. But in @theglibc{} the implementation of
1723 @code{strchr} is optimized in a special way so that @code{strchr}
1724 actually is faster.
1725
1726 @comment string.h
1727 @comment ISO
1728 @deftypefun {char *} strrchr (const char *@var{string}, int @var{c})
1729 The function @code{strrchr} is like @code{strchr}, except that it searches
1730 backwards from the end of the string @var{string} (instead of forwards
1731 from the front).
1732
1733 For example,
1734 @smallexample
1735 strrchr ("hello, world", 'l')
1736 @result{} "ld"
1737 @end smallexample
1738 @end deftypefun
1739
1740 @comment wchar.h
1741 @comment ISO
1742 @deftypefun {wchar_t *} wcsrchr (const wchar_t *@var{wstring}, wchar_t @var{c})
1743 The function @code{wcsrchr} is like @code{wcschr}, except that it searches
1744 backwards from the end of the string @var{wstring} (instead of forwards
1745 from the front).
1746 @end deftypefun
1747
1748 @comment string.h
1749 @comment ISO
1750 @deftypefun {char *} strstr (const char *@var{haystack}, const char *@var{needle})
1751 This is like @code{strchr}, except that it searches @var{haystack} for a
1752 substring @var{needle} rather than just a single character. It
1753 returns a pointer into the string @var{haystack} that is the first
1754 character of the substring, or a null pointer if no match was found. If
1755 @var{needle} is an empty string, the function returns @var{haystack}.
1756
1757 For example,
1758 @smallexample
1759 strstr ("hello, world", "l")
1760 @result{} "llo, world"
1761 strstr ("hello, world", "wo")
1762 @result{} "world"
1763 @end smallexample
1764 @end deftypefun
1765
1766 @comment wchar.h
1767 @comment ISO
1768 @deftypefun {wchar_t *} wcsstr (const wchar_t *@var{haystack}, const wchar_t *@var{needle})
1769 This is like @code{wcschr}, except that it searches @var{haystack} for a
1770 substring @var{needle} rather than just a single wide character. It
1771 returns a pointer into the string @var{haystack} that is the first wide
1772 character of the substring, or a null pointer if no match was found. If
1773 @var{needle} is an empty string, the function returns @var{haystack}.
1774 @end deftypefun
1775
1776 @comment wchar.h
1777 @comment XPG
1778 @deftypefun {wchar_t *} wcswcs (const wchar_t *@var{haystack}, const wchar_t *@var{needle})
1779 @code{wcswcs} is an deprecated alias for @code{wcsstr}. This is the
1780 name originally used in the X/Open Portability Guide before the
1781 @w{Amendment 1} to @w{ISO C90} was published.
1782 @end deftypefun
1783
1784
1785 @comment string.h
1786 @comment GNU
1787 @deftypefun {char *} strcasestr (const char *@var{haystack}, const char *@var{needle})
1788 This is like @code{strstr}, except that it ignores case in searching for
1789 the substring. Like @code{strcasecmp}, it is locale dependent how
1790 uppercase and lowercase characters are related.
1791
1792
1793 For example,
1794 @smallexample
1795 strcasestr ("hello, world", "L")
1796 @result{} "llo, world"
1797 strcasestr ("hello, World", "wo")
1798 @result{} "World"
1799 @end smallexample
1800 @end deftypefun
1801
1802
1803 @comment string.h
1804 @comment GNU
1805 @deftypefun {void *} memmem (const void *@var{haystack}, size_t @var{haystack-len},@*const void *@var{needle}, size_t @var{needle-len})
1806 This is like @code{strstr}, but @var{needle} and @var{haystack} are byte
1807 arrays rather than null-terminated strings. @var{needle-len} is the
1808 length of @var{needle} and @var{haystack-len} is the length of
1809 @var{haystack}.@refill
1810
1811 This function is a GNU extension.
1812 @end deftypefun
1813
1814 @comment string.h
1815 @comment ISO
1816 @deftypefun size_t strspn (const char *@var{string}, const char *@var{skipset})
1817 The @code{strspn} (``string span'') function returns the length of the
1818 initial substring of @var{string} that consists entirely of characters that
1819 are members of the set specified by the string @var{skipset}. The order
1820 of the characters in @var{skipset} is not important.
1821
1822 For example,
1823 @smallexample
1824 strspn ("hello, world", "abcdefghijklmnopqrstuvwxyz")
1825 @result{} 5
1826 @end smallexample
1827
1828 Note that ``character'' is here used in the sense of byte. In a string
1829 using a multibyte character encoding (abstract) character consisting of
1830 more than one byte are not treated as an entity. Each byte is treated
1831 separately. The function is not locale-dependent.
1832 @end deftypefun
1833
1834 @comment wchar.h
1835 @comment ISO
1836 @deftypefun size_t wcsspn (const wchar_t *@var{wstring}, const wchar_t *@var{skipset})
1837 The @code{wcsspn} (``wide character string span'') function returns the
1838 length of the initial substring of @var{wstring} that consists entirely
1839 of wide characters that are members of the set specified by the string
1840 @var{skipset}. The order of the wide characters in @var{skipset} is not
1841 important.
1842 @end deftypefun
1843
1844 @comment string.h
1845 @comment ISO
1846 @deftypefun size_t strcspn (const char *@var{string}, const char *@var{stopset})
1847 The @code{strcspn} (``string complement span'') function returns the length
1848 of the initial substring of @var{string} that consists entirely of characters
1849 that are @emph{not} members of the set specified by the string @var{stopset}.
1850 (In other words, it returns the offset of the first character in @var{string}
1851 that is a member of the set @var{stopset}.)
1852
1853 For example,
1854 @smallexample
1855 strcspn ("hello, world", " \t\n,.;!?")
1856 @result{} 5
1857 @end smallexample
1858
1859 Note that ``character'' is here used in the sense of byte. In a string
1860 using a multibyte character encoding (abstract) character consisting of
1861 more than one byte are not treated as an entity. Each byte is treated
1862 separately. The function is not locale-dependent.
1863 @end deftypefun
1864
1865 @comment wchar.h
1866 @comment ISO
1867 @deftypefun size_t wcscspn (const wchar_t *@var{wstring}, const wchar_t *@var{stopset})
1868 The @code{wcscspn} (``wide character string complement span'') function
1869 returns the length of the initial substring of @var{wstring} that
1870 consists entirely of wide characters that are @emph{not} members of the
1871 set specified by the string @var{stopset}. (In other words, it returns
1872 the offset of the first character in @var{string} that is a member of
1873 the set @var{stopset}.)
1874 @end deftypefun
1875
1876 @comment string.h
1877 @comment ISO
1878 @deftypefun {char *} strpbrk (const char *@var{string}, const char *@var{stopset})
1879 The @code{strpbrk} (``string pointer break'') function is related to
1880 @code{strcspn}, except that it returns a pointer to the first character
1881 in @var{string} that is a member of the set @var{stopset} instead of the
1882 length of the initial substring. It returns a null pointer if no such
1883 character from @var{stopset} is found.
1884
1885 @c @group Invalid outside the example.
1886 For example,
1887
1888 @smallexample
1889 strpbrk ("hello, world", " \t\n,.;!?")
1890 @result{} ", world"
1891 @end smallexample
1892 @c @end group
1893
1894 Note that ``character'' is here used in the sense of byte. In a string
1895 using a multibyte character encoding (abstract) character consisting of
1896 more than one byte are not treated as an entity. Each byte is treated
1897 separately. The function is not locale-dependent.
1898 @end deftypefun
1899
1900 @comment wchar.h
1901 @comment ISO
1902 @deftypefun {wchar_t *} wcspbrk (const wchar_t *@var{wstring}, const wchar_t *@var{stopset})
1903 The @code{wcspbrk} (``wide character string pointer break'') function is
1904 related to @code{wcscspn}, except that it returns a pointer to the first
1905 wide character in @var{wstring} that is a member of the set
1906 @var{stopset} instead of the length of the initial substring. It
1907 returns a null pointer if no such character from @var{stopset} is found.
1908 @end deftypefun
1909
1910
1911 @subsection Compatibility String Search Functions
1912
1913 @comment string.h
1914 @comment BSD
1915 @deftypefun {char *} index (const char *@var{string}, int @var{c})
1916 @code{index} is another name for @code{strchr}; they are exactly the same.
1917 New code should always use @code{strchr} since this name is defined in
1918 @w{ISO C} while @code{index} is a BSD invention which never was available
1919 on @w{System V} derived systems.
1920 @end deftypefun
1921
1922 @comment string.h
1923 @comment BSD
1924 @deftypefun {char *} rindex (const char *@var{string}, int @var{c})
1925 @code{rindex} is another name for @code{strrchr}; they are exactly the same.
1926 New code should always use @code{strrchr} since this name is defined in
1927 @w{ISO C} while @code{rindex} is a BSD invention which never was available
1928 on @w{System V} derived systems.
1929 @end deftypefun
1930
1931 @node Finding Tokens in a String
1932 @section Finding Tokens in a String
1933
1934 @cindex tokenizing strings
1935 @cindex breaking a string into tokens
1936 @cindex parsing tokens from a string
1937 It's fairly common for programs to have a need to do some simple kinds
1938 of lexical analysis and parsing, such as splitting a command string up
1939 into tokens. You can do this with the @code{strtok} function, declared
1940 in the header file @file{string.h}.
1941 @pindex string.h
1942
1943 @comment string.h
1944 @comment ISO
1945 @deftypefun {char *} strtok (char *restrict @var{newstring}, const char *restrict @var{delimiters})
1946 A string can be split into tokens by making a series of calls to the
1947 function @code{strtok}.
1948
1949 The string to be split up is passed as the @var{newstring} argument on
1950 the first call only. The @code{strtok} function uses this to set up
1951 some internal state information. Subsequent calls to get additional
1952 tokens from the same string are indicated by passing a null pointer as
1953 the @var{newstring} argument. Calling @code{strtok} with another
1954 non-null @var{newstring} argument reinitializes the state information.
1955 It is guaranteed that no other library function ever calls @code{strtok}
1956 behind your back (which would mess up this internal state information).
1957
1958 The @var{delimiters} argument is a string that specifies a set of delimiters
1959 that may surround the token being extracted. All the initial characters
1960 that are members of this set are discarded. The first character that is
1961 @emph{not} a member of this set of delimiters marks the beginning of the
1962 next token. The end of the token is found by looking for the next
1963 character that is a member of the delimiter set. This character in the
1964 original string @var{newstring} is overwritten by a null character, and the
1965 pointer to the beginning of the token in @var{newstring} is returned.
1966
1967 On the next call to @code{strtok}, the searching begins at the next
1968 character beyond the one that marked the end of the previous token.
1969 Note that the set of delimiters @var{delimiters} do not have to be the
1970 same on every call in a series of calls to @code{strtok}.
1971
1972 If the end of the string @var{newstring} is reached, or if the remainder of
1973 string consists only of delimiter characters, @code{strtok} returns
1974 a null pointer.
1975
1976 Note that ``character'' is here used in the sense of byte. In a string
1977 using a multibyte character encoding (abstract) character consisting of
1978 more than one byte are not treated as an entity. Each byte is treated
1979 separately. The function is not locale-dependent.
1980 @end deftypefun
1981
1982 @comment wchar.h
1983 @comment ISO
1984 @deftypefun {wchar_t *} wcstok (wchar_t *@var{newstring}, const char *@var{delimiters})
1985 A string can be split into tokens by making a series of calls to the
1986 function @code{wcstok}.
1987
1988 The string to be split up is passed as the @var{newstring} argument on
1989 the first call only. The @code{wcstok} function uses this to set up
1990 some internal state information. Subsequent calls to get additional
1991 tokens from the same wide character string are indicated by passing a
1992 null pointer as the @var{newstring} argument. Calling @code{wcstok}
1993 with another non-null @var{newstring} argument reinitializes the state
1994 information. It is guaranteed that no other library function ever calls
1995 @code{wcstok} behind your back (which would mess up this internal state
1996 information).
1997
1998 The @var{delimiters} argument is a wide character string that specifies
1999 a set of delimiters that may surround the token being extracted. All
2000 the initial wide characters that are members of this set are discarded.
2001 The first wide character that is @emph{not} a member of this set of
2002 delimiters marks the beginning of the next token. The end of the token
2003 is found by looking for the next wide character that is a member of the
2004 delimiter set. This wide character in the original wide character
2005 string @var{newstring} is overwritten by a null wide character, and the
2006 pointer to the beginning of the token in @var{newstring} is returned.
2007
2008 On the next call to @code{wcstok}, the searching begins at the next
2009 wide character beyond the one that marked the end of the previous token.
2010 Note that the set of delimiters @var{delimiters} do not have to be the
2011 same on every call in a series of calls to @code{wcstok}.
2012
2013 If the end of the wide character string @var{newstring} is reached, or
2014 if the remainder of string consists only of delimiter wide characters,
2015 @code{wcstok} returns a null pointer.
2016
2017 Note that ``character'' is here used in the sense of byte. In a string
2018 using a multibyte character encoding (abstract) character consisting of
2019 more than one byte are not treated as an entity. Each byte is treated
2020 separately. The function is not locale-dependent.
2021 @end deftypefun
2022
2023 @strong{Warning:} Since @code{strtok} and @code{wcstok} alter the string
2024 they is parsing, you should always copy the string to a temporary buffer
2025 before parsing it with @code{strtok}/@code{wcstok} (@pxref{Copying and
2026 Concatenation}). If you allow @code{strtok} or @code{wcstok} to modify
2027 a string that came from another part of your program, you are asking for
2028 trouble; that string might be used for other purposes after
2029 @code{strtok} or @code{wcstok} has modified it, and it would not have
2030 the expected value.
2031
2032 The string that you are operating on might even be a constant. Then
2033 when @code{strtok} or @code{wcstok} tries to modify it, your program
2034 will get a fatal signal for writing in read-only memory. @xref{Program
2035 Error Signals}. Even if the operation of @code{strtok} or @code{wcstok}
2036 would not require a modification of the string (e.g., if there is
2037 exactly one token) the string can (and in the @glibcadj{} case will) be
2038 modified.
2039
2040 This is a special case of a general principle: if a part of a program
2041 does not have as its purpose the modification of a certain data
2042 structure, then it is error-prone to modify the data structure
2043 temporarily.
2044
2045 The functions @code{strtok} and @code{wcstok} are not reentrant.
2046 @xref{Nonreentrancy}, for a discussion of where and why reentrancy is
2047 important.
2048
2049 Here is a simple example showing the use of @code{strtok}.
2050
2051 @comment Yes, this example has been tested.
2052 @smallexample
2053 #include <string.h>
2054 #include <stddef.h>
2055
2056 @dots{}
2057
2058 const char string[] = "words separated by spaces -- and, punctuation!";
2059 const char delimiters[] = " .,;:!-";
2060 char *token, *cp;
2061
2062 @dots{}
2063
2064 cp = strdupa (string); /* Make writable copy. */
2065 token = strtok (cp, delimiters); /* token => "words" */
2066 token = strtok (NULL, delimiters); /* token => "separated" */
2067 token = strtok (NULL, delimiters); /* token => "by" */
2068 token = strtok (NULL, delimiters); /* token => "spaces" */
2069 token = strtok (NULL, delimiters); /* token => "and" */
2070 token = strtok (NULL, delimiters); /* token => "punctuation" */
2071 token = strtok (NULL, delimiters); /* token => NULL */
2072 @end smallexample
2073
2074 @Theglibc{} contains two more functions for tokenizing a string
2075 which overcome the limitation of non-reentrancy. They are only
2076 available for multibyte character strings.
2077
2078 @comment string.h
2079 @comment POSIX
2080 @deftypefun {char *} strtok_r (char *@var{newstring}, const char *@var{delimiters}, char **@var{save_ptr})
2081 Just like @code{strtok}, this function splits the string into several
2082 tokens which can be accessed by successive calls to @code{strtok_r}.
2083 The difference is that the information about the next token is stored in
2084 the space pointed to by the third argument, @var{save_ptr}, which is a
2085 pointer to a string pointer. Calling @code{strtok_r} with a null
2086 pointer for @var{newstring} and leaving @var{save_ptr} between the calls
2087 unchanged does the job without hindering reentrancy.
2088
2089 This function is defined in POSIX.1 and can be found on many systems
2090 which support multi-threading.
2091 @end deftypefun
2092
2093 @comment string.h
2094 @comment BSD
2095 @deftypefun {char *} strsep (char **@var{string_ptr}, const char *@var{delimiter})
2096 This function has a similar functionality as @code{strtok_r} with the
2097 @var{newstring} argument replaced by the @var{save_ptr} argument. The
2098 initialization of the moving pointer has to be done by the user.
2099 Successive calls to @code{strsep} move the pointer along the tokens
2100 separated by @var{delimiter}, returning the address of the next token
2101 and updating @var{string_ptr} to point to the beginning of the next
2102 token.
2103
2104 One difference between @code{strsep} and @code{strtok_r} is that if the
2105 input string contains more than one character from @var{delimiter} in a
2106 row @code{strsep} returns an empty string for each pair of characters
2107 from @var{delimiter}. This means that a program normally should test
2108 for @code{strsep} returning an empty string before processing it.
2109
2110 This function was introduced in 4.3BSD and therefore is widely available.
2111 @end deftypefun
2112
2113 Here is how the above example looks like when @code{strsep} is used.
2114
2115 @comment Yes, this example has been tested.
2116 @smallexample
2117 #include <string.h>
2118 #include <stddef.h>
2119
2120 @dots{}
2121
2122 const char string[] = "words separated by spaces -- and, punctuation!";
2123 const char delimiters[] = " .,;:!-";
2124 char *running;
2125 char *token;
2126
2127 @dots{}
2128
2129 running = strdupa (string);
2130 token = strsep (&running, delimiters); /* token => "words" */
2131 token = strsep (&running, delimiters); /* token => "separated" */
2132 token = strsep (&running, delimiters); /* token => "by" */
2133 token = strsep (&running, delimiters); /* token => "spaces" */
2134 token = strsep (&running, delimiters); /* token => "" */
2135 token = strsep (&running, delimiters); /* token => "" */
2136 token = strsep (&running, delimiters); /* token => "" */
2137 token = strsep (&running, delimiters); /* token => "and" */
2138 token = strsep (&running, delimiters); /* token => "" */
2139 token = strsep (&running, delimiters); /* token => "punctuation" */
2140 token = strsep (&running, delimiters); /* token => "" */
2141 token = strsep (&running, delimiters); /* token => NULL */
2142 @end smallexample
2143
2144 @comment string.h
2145 @comment GNU
2146 @deftypefun {char *} basename (const char *@var{filename})
2147 The GNU version of the @code{basename} function returns the last
2148 component of the path in @var{filename}. This function is the preferred
2149 usage, since it does not modify the argument, @var{filename}, and
2150 respects trailing slashes. The prototype for @code{basename} can be
2151 found in @file{string.h}. Note, this function is overriden by the XPG
2152 version, if @file{libgen.h} is included.
2153
2154 Example of using GNU @code{basename}:
2155
2156 @smallexample
2157 #include <string.h>
2158
2159 int
2160 main (int argc, char *argv[])
2161 @{
2162 char *prog = basename (argv[0]);
2163
2164 if (argc < 2)
2165 @{
2166 fprintf (stderr, "Usage %s <arg>\n", prog);
2167 exit (1);
2168 @}
2169
2170 @dots{}
2171 @}
2172 @end smallexample
2173
2174 @strong{Portability Note:} This function may produce different results
2175 on different systems.
2176
2177 @end deftypefun
2178
2179 @comment libgen.h
2180 @comment XPG
2181 @deftypefun {char *} basename (char *@var{path})
2182 This is the standard XPG defined @code{basename}. It is similar in
2183 spirit to the GNU version, but may modify the @var{path} by removing
2184 trailing '/' characters. If the @var{path} is made up entirely of '/'
2185 characters, then "/" will be returned. Also, if @var{path} is
2186 @code{NULL} or an empty string, then "." is returned. The prototype for
2187 the XPG version can be found in @file{libgen.h}.
2188
2189 Example of using XPG @code{basename}:
2190
2191 @smallexample
2192 #include <libgen.h>
2193
2194 int
2195 main (int argc, char *argv[])
2196 @{
2197 char *prog;
2198 char *path = strdupa (argv[0]);
2199
2200 prog = basename (path);
2201
2202 if (argc < 2)
2203 @{
2204 fprintf (stderr, "Usage %s <arg>\n", prog);
2205 exit (1);
2206 @}
2207
2208 @dots{}
2209
2210 @}
2211 @end smallexample
2212 @end deftypefun
2213
2214 @comment libgen.h
2215 @comment XPG
2216 @deftypefun {char *} dirname (char *@var{path})
2217 The @code{dirname} function is the compliment to the XPG version of
2218 @code{basename}. It returns the parent directory of the file specified
2219 by @var{path}. If @var{path} is @code{NULL}, an empty string, or
2220 contains no '/' characters, then "." is returned. The prototype for this
2221 function can be found in @file{libgen.h}.
2222 @end deftypefun
2223
2224 @node strfry
2225 @section strfry
2226
2227 The function below addresses the perennial programming quandary: ``How do
2228 I take good data in string form and painlessly turn it into garbage?''
2229 This is actually a fairly simple task for C programmers who do not use
2230 @theglibc{} string functions, but for programs based on @theglibc{},
2231 the @code{strfry} function is the preferred method for
2232 destroying string data.
2233
2234 The prototype for this function is in @file{string.h}.
2235
2236 @comment string.h
2237 @comment GNU
2238 @deftypefun {char *} strfry (char *@var{string})
2239
2240 @code{strfry} creates a pseudorandom anagram of a string, replacing the
2241 input with the anagram in place. For each position in the string,
2242 @code{strfry} swaps it with a position in the string selected at random
2243 (from a uniform distribution). The two positions may be the same.
2244
2245 The return value of @code{strfry} is always @var{string}.
2246
2247 @strong{Portability Note:} This function is unique to @theglibc{}.
2248
2249 @end deftypefun
2250
2251
2252 @node Trivial Encryption
2253 @section Trivial Encryption
2254 @cindex encryption
2255
2256
2257 The @code{memfrob} function converts an array of data to something
2258 unrecognizable and back again. It is not encryption in its usual sense
2259 since it is easy for someone to convert the encrypted data back to clear
2260 text. The transformation is analogous to Usenet's ``Rot13'' encryption
2261 method for obscuring offensive jokes from sensitive eyes and such.
2262 Unlike Rot13, @code{memfrob} works on arbitrary binary data, not just
2263 text.
2264 @cindex Rot13
2265
2266 For true encryption, @xref{Cryptographic Functions}.
2267
2268 This function is declared in @file{string.h}.
2269 @pindex string.h
2270
2271 @comment string.h
2272 @comment GNU
2273 @deftypefun {void *} memfrob (void *@var{mem}, size_t @var{length})
2274
2275 @code{memfrob} transforms (frobnicates) each byte of the data structure
2276 at @var{mem}, which is @var{length} bytes long, by bitwise exclusive
2277 oring it with binary 00101010. It does the transformation in place and
2278 its return value is always @var{mem}.
2279
2280 Note that @code{memfrob} a second time on the same data structure
2281 returns it to its original state.
2282
2283 This is a good function for hiding information from someone who doesn't
2284 want to see it or doesn't want to see it very much. To really prevent
2285 people from retrieving the information, use stronger encryption such as
2286 that described in @xref{Cryptographic Functions}.
2287
2288 @strong{Portability Note:} This function is unique to @theglibc{}.
2289
2290 @end deftypefun
2291
2292 @node Encode Binary Data
2293 @section Encode Binary Data
2294
2295 To store or transfer binary data in environments which only support text
2296 one has to encode the binary data by mapping the input bytes to
2297 characters in the range allowed for storing or transfering. SVID
2298 systems (and nowadays XPG compliant systems) provide minimal support for
2299 this task.
2300
2301 @comment stdlib.h
2302 @comment XPG
2303 @deftypefun {char *} l64a (long int @var{n})
2304 This function encodes a 32-bit input value using characters from the
2305 basic character set. It returns a pointer to a 7 character buffer which
2306 contains an encoded version of @var{n}. To encode a series of bytes the
2307 user must copy the returned string to a destination buffer. It returns
2308 the empty string if @var{n} is zero, which is somewhat bizarre but
2309 mandated by the standard.@*
2310 @strong{Warning:} Since a static buffer is used this function should not
2311 be used in multi-threaded programs. There is no thread-safe alternative
2312 to this function in the C library.@*
2313 @strong{Compatibility Note:} The XPG standard states that the return
2314 value of @code{l64a} is undefined if @var{n} is negative. In the GNU
2315 implementation, @code{l64a} treats its argument as unsigned, so it will
2316 return a sensible encoding for any nonzero @var{n}; however, portable
2317 programs should not rely on this.
2318
2319 To encode a large buffer @code{l64a} must be called in a loop, once for
2320 each 32-bit word of the buffer. For example, one could do something
2321 like this:
2322
2323 @smallexample
2324 char *
2325 encode (const void *buf, size_t len)
2326 @{
2327 /* @r{We know in advance how long the buffer has to be.} */
2328 unsigned char *in = (unsigned char *) buf;
2329 char *out = malloc (6 + ((len + 3) / 4) * 6 + 1);
2330 char *cp = out, *p;
2331
2332 /* @r{Encode the length.} */
2333 /* @r{Using `htonl' is necessary so that the data can be}
2334 @r{decoded even on machines with different byte order.}
2335 @r{`l64a' can return a string shorter than 6 bytes, so }
2336 @r{we pad it with encoding of 0 (}'.'@r{) at the end by }
2337 @r{hand.} */
2338
2339 p = stpcpy (cp, l64a (htonl (len)));
2340 cp = mempcpy (p, "......", 6 - (p - cp));
2341
2342 while (len > 3)
2343 @{
2344 unsigned long int n = *in++;
2345 n = (n << 8) | *in++;
2346 n = (n << 8) | *in++;
2347 n = (n << 8) | *in++;
2348 len -= 4;
2349 p = stpcpy (cp, l64a (htonl (n)));
2350 cp = mempcpy (p, "......", 6 - (p - cp));
2351 @}
2352 if (len > 0)
2353 @{
2354 unsigned long int n = *in++;
2355 if (--len > 0)
2356 @{
2357 n = (n << 8) | *in++;
2358 if (--len > 0)
2359 n = (n << 8) | *in;
2360 @}
2361 cp = stpcpy (cp, l64a (htonl (n)));
2362 @}
2363 *cp = '\0';
2364 return out;
2365 @}
2366 @end smallexample
2367
2368 It is strange that the library does not provide the complete
2369 functionality needed but so be it.
2370
2371 @end deftypefun
2372
2373 To decode data produced with @code{l64a} the following function should be
2374 used.
2375
2376 @comment stdlib.h
2377 @comment XPG
2378 @deftypefun {long int} a64l (const char *@var{string})
2379 The parameter @var{string} should contain a string which was produced by
2380 a call to @code{l64a}. The function processes at least 6 characters of
2381 this string, and decodes the characters it finds according to the table
2382 below. It stops decoding when it finds a character not in the table,
2383 rather like @code{atoi}; if you have a buffer which has been broken into
2384 lines, you must be careful to skip over the end-of-line characters.
2385
2386 The decoded number is returned as a @code{long int} value.
2387 @end deftypefun
2388
2389 The @code{l64a} and @code{a64l} functions use a base 64 encoding, in
2390 which each character of an encoded string represents six bits of an
2391 input word. These symbols are used for the base 64 digits:
2392
2393 @multitable {xxxxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx}
2394 @item @tab 0 @tab 1 @tab 2 @tab 3 @tab 4 @tab 5 @tab 6 @tab 7
2395 @item 0 @tab @code{.} @tab @code{/} @tab @code{0} @tab @code{1}
2396 @tab @code{2} @tab @code{3} @tab @code{4} @tab @code{5}
2397 @item 8 @tab @code{6} @tab @code{7} @tab @code{8} @tab @code{9}
2398 @tab @code{A} @tab @code{B} @tab @code{C} @tab @code{D}
2399 @item 16 @tab @code{E} @tab @code{F} @tab @code{G} @tab @code{H}
2400 @tab @code{I} @tab @code{J} @tab @code{K} @tab @code{L}
2401 @item 24 @tab @code{M} @tab @code{N} @tab @code{O} @tab @code{P}
2402 @tab @code{Q} @tab @code{R} @tab @code{S} @tab @code{T}
2403 @item 32 @tab @code{U} @tab @code{V} @tab @code{W} @tab @code{X}
2404 @tab @code{Y} @tab @code{Z} @tab @code{a} @tab @code{b}
2405 @item 40 @tab @code{c} @tab @code{d} @tab @code{e} @tab @code{f}
2406 @tab @code{g} @tab @code{h} @tab @code{i} @tab @code{j}
2407 @item 48 @tab @code{k} @tab @code{l} @tab @code{m} @tab @code{n}
2408 @tab @code{o} @tab @code{p} @tab @code{q} @tab @code{r}
2409 @item 56 @tab @code{s} @tab @code{t} @tab @code{u} @tab @code{v}
2410 @tab @code{w} @tab @code{x} @tab @code{y} @tab @code{z}
2411 @end multitable
2412
2413 This encoding scheme is not standard. There are some other encoding
2414 methods which are much more widely used (UU encoding, MIME encoding).
2415 Generally, it is better to use one of these encodings.
2416
2417 @node Argz and Envz Vectors
2418 @section Argz and Envz Vectors
2419
2420 @cindex argz vectors (string vectors)
2421 @cindex string vectors, null-character separated
2422 @cindex argument vectors, null-character separated
2423 @dfn{argz vectors} are vectors of strings in a contiguous block of
2424 memory, each element separated from its neighbors by null-characters
2425 (@code{'\0'}).
2426
2427 @cindex envz vectors (environment vectors)
2428 @cindex environment vectors, null-character separated
2429 @dfn{Envz vectors} are an extension of argz vectors where each element is a
2430 name-value pair, separated by a @code{'='} character (as in a Unix
2431 environment).
2432
2433 @menu
2434 * Argz Functions:: Operations on argz vectors.
2435 * Envz Functions:: Additional operations on environment vectors.
2436 @end menu
2437
2438 @node Argz Functions, Envz Functions, , Argz and Envz Vectors
2439 @subsection Argz Functions
2440
2441 Each argz vector is represented by a pointer to the first element, of
2442 type @code{char *}, and a size, of type @code{size_t}, both of which can
2443 be initialized to @code{0} to represent an empty argz vector. All argz
2444 functions accept either a pointer and a size argument, or pointers to
2445 them, if they will be modified.
2446
2447 The argz functions use @code{malloc}/@code{realloc} to allocate/grow
2448 argz vectors, and so any argz vector creating using these functions may
2449 be freed by using @code{free}; conversely, any argz function that may
2450 grow a string expects that string to have been allocated using
2451 @code{malloc} (those argz functions that only examine their arguments or
2452 modify them in place will work on any sort of memory).
2453 @xref{Unconstrained Allocation}.
2454
2455 All argz functions that do memory allocation have a return type of
2456 @code{error_t}, and return @code{0} for success, and @code{ENOMEM} if an
2457 allocation error occurs.
2458
2459 @pindex argz.h
2460 These functions are declared in the standard include file @file{argz.h}.
2461
2462 @comment argz.h
2463 @comment GNU
2464 @deftypefun {error_t} argz_create (char *const @var{argv}[], char **@var{argz}, size_t *@var{argz_len})
2465 The @code{argz_create} function converts the Unix-style argument vector
2466 @var{argv} (a vector of pointers to normal C strings, terminated by
2467 @code{(char *)0}; @pxref{Program Arguments}) into an argz vector with
2468 the same elements, which is returned in @var{argz} and @var{argz_len}.
2469 @end deftypefun
2470
2471 @comment argz.h
2472 @comment GNU
2473 @deftypefun {error_t} argz_create_sep (const char *@var{string}, int @var{sep}, char **@var{argz}, size_t *@var{argz_len})
2474 The @code{argz_create_sep} function converts the null-terminated string
2475 @var{string} into an argz vector (returned in @var{argz} and
2476 @var{argz_len}) by splitting it into elements at every occurrence of the
2477 character @var{sep}.
2478 @end deftypefun
2479
2480 @comment argz.h
2481 @comment GNU
2482 @deftypefun {size_t} argz_count (const char *@var{argz}, size_t @var{arg_len})
2483 Returns the number of elements in the argz vector @var{argz} and
2484 @var{argz_len}.
2485 @end deftypefun
2486
2487 @comment argz.h
2488 @comment GNU
2489 @deftypefun {void} argz_extract (char *@var{argz}, size_t @var{argz_len}, char **@var{argv})
2490 The @code{argz_extract} function converts the argz vector @var{argz} and
2491 @var{argz_len} into a Unix-style argument vector stored in @var{argv},
2492 by putting pointers to every element in @var{argz} into successive
2493 positions in @var{argv}, followed by a terminator of @code{0}.
2494 @var{Argv} must be pre-allocated with enough space to hold all the
2495 elements in @var{argz} plus the terminating @code{(char *)0}
2496 (@code{(argz_count (@var{argz}, @var{argz_len}) + 1) * sizeof (char *)}
2497 bytes should be enough). Note that the string pointers stored into
2498 @var{argv} point into @var{argz}---they are not copies---and so
2499 @var{argz} must be copied if it will be changed while @var{argv} is
2500 still active. This function is useful for passing the elements in
2501 @var{argz} to an exec function (@pxref{Executing a File}).
2502 @end deftypefun
2503
2504 @comment argz.h
2505 @comment GNU
2506 @deftypefun {void} argz_stringify (char *@var{argz}, size_t @var{len}, int @var{sep})
2507 The @code{argz_stringify} converts @var{argz} into a normal string with
2508 the elements separated by the character @var{sep}, by replacing each
2509 @code{'\0'} inside @var{argz} (except the last one, which terminates the
2510 string) with @var{sep}. This is handy for printing @var{argz} in a
2511 readable manner.
2512 @end deftypefun
2513
2514 @comment argz.h
2515 @comment GNU
2516 @deftypefun {error_t} argz_add (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str})
2517 The @code{argz_add} function adds the string @var{str} to the end of the
2518 argz vector @code{*@var{argz}}, and updates @code{*@var{argz}} and
2519 @code{*@var{argz_len}} accordingly.
2520 @end deftypefun
2521
2522 @comment argz.h
2523 @comment GNU
2524 @deftypefun {error_t} argz_add_sep (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str}, int @var{delim})
2525 The @code{argz_add_sep} function is similar to @code{argz_add}, but
2526 @var{str} is split into separate elements in the result at occurrences of
2527 the character @var{delim}. This is useful, for instance, for
2528 adding the components of a Unix search path to an argz vector, by using
2529 a value of @code{':'} for @var{delim}.
2530 @end deftypefun
2531
2532 @comment argz.h
2533 @comment GNU
2534 @deftypefun {error_t} argz_append (char **@var{argz}, size_t *@var{argz_len}, const char *@var{buf}, size_t @var{buf_len})
2535 The @code{argz_append} function appends @var{buf_len} bytes starting at
2536 @var{buf} to the argz vector @code{*@var{argz}}, reallocating
2537 @code{*@var{argz}} to accommodate it, and adding @var{buf_len} to
2538 @code{*@var{argz_len}}.
2539 @end deftypefun
2540
2541 @comment argz.h
2542 @comment GNU
2543 @deftypefun {void} argz_delete (char **@var{argz}, size_t *@var{argz_len}, char *@var{entry})
2544 If @var{entry} points to the beginning of one of the elements in the
2545 argz vector @code{*@var{argz}}, the @code{argz_delete} function will
2546 remove this entry and reallocate @code{*@var{argz}}, modifying
2547 @code{*@var{argz}} and @code{*@var{argz_len}} accordingly. Note that as
2548 destructive argz functions usually reallocate their argz argument,
2549 pointers into argz vectors such as @var{entry} will then become invalid.
2550 @end deftypefun
2551
2552 @comment argz.h
2553 @comment GNU
2554 @deftypefun {error_t} argz_insert (char **@var{argz}, size_t *@var{argz_len}, char *@var{before}, const char *@var{entry})
2555 The @code{argz_insert} function inserts the string @var{entry} into the
2556 argz vector @code{*@var{argz}} at a point just before the existing
2557 element pointed to by @var{before}, reallocating @code{*@var{argz}} and
2558 updating @code{*@var{argz}} and @code{*@var{argz_len}}. If @var{before}
2559 is @code{0}, @var{entry} is added to the end instead (as if by
2560 @code{argz_add}). Since the first element is in fact the same as
2561 @code{*@var{argz}}, passing in @code{*@var{argz}} as the value of
2562 @var{before} will result in @var{entry} being inserted at the beginning.
2563 @end deftypefun
2564
2565 @comment argz.h
2566 @comment GNU
2567 @deftypefun {char *} argz_next (char *@var{argz}, size_t @var{argz_len}, const char *@var{entry})
2568 The @code{argz_next} function provides a convenient way of iterating
2569 over the elements in the argz vector @var{argz}. It returns a pointer
2570 to the next element in @var{argz} after the element @var{entry}, or
2571 @code{0} if there are no elements following @var{entry}. If @var{entry}
2572 is @code{0}, the first element of @var{argz} is returned.
2573
2574 This behavior suggests two styles of iteration:
2575
2576 @smallexample
2577 char *entry = 0;
2578 while ((entry = argz_next (@var{argz}, @var{argz_len}, entry)))
2579 @var{action};
2580 @end smallexample
2581
2582 (the double parentheses are necessary to make some C compilers shut up
2583 about what they consider a questionable @code{while}-test) and:
2584
2585 @smallexample
2586 char *entry;
2587 for (entry = @var{argz};
2588 entry;
2589 entry = argz_next (@var{argz}, @var{argz_len}, entry))
2590 @var{action};
2591 @end smallexample
2592
2593 Note that the latter depends on @var{argz} having a value of @code{0} if
2594 it is empty (rather than a pointer to an empty block of memory); this
2595 invariant is maintained for argz vectors created by the functions here.
2596 @end deftypefun
2597
2598 @comment argz.h
2599 @comment GNU
2600 @deftypefun error_t argz_replace (@w{char **@var{argz}, size_t *@var{argz_len}}, @w{const char *@var{str}, const char *@var{with}}, @w{unsigned *@var{replace_count}})
2601 Replace any occurrences of the string @var{str} in @var{argz} with
2602 @var{with}, reallocating @var{argz} as necessary. If
2603 @var{replace_count} is non-zero, @code{*@var{replace_count}} will be
2604 incremented by number of replacements performed.
2605 @end deftypefun
2606
2607 @node Envz Functions, , Argz Functions, Argz and Envz Vectors
2608 @subsection Envz Functions
2609
2610 Envz vectors are just argz vectors with additional constraints on the form
2611 of each element; as such, argz functions can also be used on them, where it
2612 makes sense.
2613
2614 Each element in an envz vector is a name-value pair, separated by a @code{'='}
2615 character; if multiple @code{'='} characters are present in an element, those
2616 after the first are considered part of the value, and treated like all other
2617 non-@code{'\0'} characters.
2618
2619 If @emph{no} @code{'='} characters are present in an element, that element is
2620 considered the name of a ``null'' entry, as distinct from an entry with an
2621 empty value: @code{envz_get} will return @code{0} if given the name of null
2622 entry, whereas an entry with an empty value would result in a value of
2623 @code{""}; @code{envz_entry} will still find such entries, however. Null
2624 entries can be removed with @code{envz_strip} function.
2625
2626 As with argz functions, envz functions that may allocate memory (and thus
2627 fail) have a return type of @code{error_t}, and return either @code{0} or
2628 @code{ENOMEM}.
2629
2630 @pindex envz.h
2631 These functions are declared in the standard include file @file{envz.h}.
2632
2633 @comment envz.h
2634 @comment GNU
2635 @deftypefun {char *} envz_entry (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
2636 The @code{envz_entry} function finds the entry in @var{envz} with the name
2637 @var{name}, and returns a pointer to the whole entry---that is, the argz
2638 element which begins with @var{name} followed by a @code{'='} character. If
2639 there is no entry with that name, @code{0} is returned.
2640 @end deftypefun
2641
2642 @comment envz.h
2643 @comment GNU
2644 @deftypefun {char *} envz_get (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
2645 The @code{envz_get} function finds the entry in @var{envz} with the name
2646 @var{name} (like @code{envz_entry}), and returns a pointer to the value
2647 portion of that entry (following the @code{'='}). If there is no entry with
2648 that name (or only a null entry), @code{0} is returned.
2649 @end deftypefun
2650
2651 @comment envz.h
2652 @comment GNU
2653 @deftypefun {error_t} envz_add (char **@var{envz}, size_t *@var{envz_len}, const char *@var{name}, const char *@var{value})
2654 The @code{envz_add} function adds an entry to @code{*@var{envz}}
2655 (updating @code{*@var{envz}} and @code{*@var{envz_len}}) with the name
2656 @var{name}, and value @var{value}. If an entry with the same name
2657 already exists in @var{envz}, it is removed first. If @var{value} is
2658 @code{0}, then the new entry will the special null type of entry
2659 (mentioned above).
2660 @end deftypefun
2661
2662 @comment envz.h
2663 @comment GNU
2664 @deftypefun {error_t} envz_merge (char **@var{envz}, size_t *@var{envz_len}, const char *@var{envz2}, size_t @var{envz2_len}, int @var{override})
2665 The @code{envz_merge} function adds each entry in @var{envz2} to @var{envz},
2666 as if with @code{envz_add}, updating @code{*@var{envz}} and
2667 @code{*@var{envz_len}}. If @var{override} is true, then values in @var{envz2}
2668 will supersede those with the same name in @var{envz}, otherwise not.
2669
2670 Null entries are treated just like other entries in this respect, so a null
2671 entry in @var{envz} can prevent an entry of the same name in @var{envz2} from
2672 being added to @var{envz}, if @var{override} is false.
2673 @end deftypefun
2674
2675 @comment envz.h
2676 @comment GNU
2677 @deftypefun {void} envz_strip (char **@var{envz}, size_t *@var{envz_len})
2678 The @code{envz_strip} function removes any null entries from @var{envz},
2679 updating @code{*@var{envz}} and @code{*@var{envz_len}}.
2680 @end deftypefun