assert: Reformat Makefile.
[glibc.git] / manual / string.texi
blobad572652748450e418fa5bb4cb6e2a0f94e0604e
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
5 Operations on strings (null-terminated byte sequences) 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.
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.
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.
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 Strings and Arrays::  Functions to copy strings and arrays.
29 * Concatenating Strings::       Functions to concatenate strings while copying.
30 * Truncating Strings::          Functions to truncate strings while copying.
31 * String/Array Comparison::     Functions for byte-wise and character-wise
32                                  comparison.
33 * Collation Functions::         Functions for collating strings.
34 * Search Functions::            Searching for a specific element or substring.
35 * Finding Tokens in a String::  Splitting a string into tokens by looking
36                                  for delimiters.
37 * Erasing Sensitive Data::      Clearing memory which contains sensitive
38                                  data, after it's no longer needed.
39 * Shuffling Bytes::             Or how to flash-cook a string.
40 * Obfuscating Data::            Reversibly obscuring data from casual view.
41 * Encode Binary Data::          Encoding and Decoding of Binary Data.
42 * Argz and Envz Vectors::       Null-separated string vectors.
43 @end menu
45 @node Representation of Strings
46 @section Representation of Strings
47 @cindex string, representation of
49 This section is a quick summary of string concepts for beginning C
50 programmers.  It describes how strings are represented in C
51 and some common pitfalls.  If you are already familiar with this
52 material, you can skip this section.
54 @cindex string
55 A @dfn{string} is a null-terminated array of bytes of type @code{char},
56 including the terminating null byte.  String-valued
57 variables are usually declared to be pointers of type @code{char *}.
58 Such variables do not include space for the contents of a string; that has
59 to be stored somewhere else---in an array variable, a string constant,
60 or dynamically allocated memory (@pxref{Memory Allocation}).  It's up to
61 you to store the address of the chosen memory space into the pointer
62 variable.  Alternatively you can store a @dfn{null pointer} in the
63 pointer variable.  The null pointer does not point anywhere, so
64 attempting to reference the string it points to gets an error.
66 @cindex multibyte character
67 @cindex multibyte string
68 @cindex wide string
69 A @dfn{multibyte character} is a sequence of one or more bytes that
70 represents a single character using the locale's encoding scheme; a
71 null byte always represents the null character.  A @dfn{multibyte
72 string} is a string that consists entirely of multibyte
73 characters.  In contrast, a @dfn{wide string} is a null-terminated
74 sequence of @code{wchar_t} objects.  A wide-string variable is usually
75 declared to be a pointer of type @code{wchar_t *}, by analogy with
76 string variables and @code{char *}.  @xref{Extended Char Intro}.
78 @cindex null byte
79 @cindex null wide character
80 By convention, the @dfn{null byte}, @code{'\0'},
81 marks the end of a string and the @dfn{null wide character},
82 @code{L'\0'}, marks the end of a wide string.  For example, in
83 testing to see whether the @code{char *} variable @var{p} points to a
84 null byte marking the end of a string, you can write
85 @code{!*@var{p}} or @code{*@var{p} == '\0'}.
87 A null byte is quite different conceptually from a null pointer,
88 although both are represented by the integer constant @code{0}.
90 @cindex string literal
91 A @dfn{string literal} appears in C program source as a multibyte
92 string between double-quote characters (@samp{"}).  If the
93 initial double-quote character is immediately preceded by a capital
94 @samp{L} (ell) character (as in @code{L"foo"}), it is a wide string
95 literal.  String literals can also contribute to @dfn{string
96 concatenation}: @code{"a" "b"} is the same as @code{"ab"}.
97 For wide strings one can use either
98 @code{L"a" L"b"} or @code{L"a" "b"}.  Modification of string literals is
99 not allowed by the GNU C compiler, because literals are placed in
100 read-only storage.
102 Arrays that are declared @code{const} cannot be modified
103 either.  It's generally good style to declare non-modifiable string
104 pointers to be of type @code{const char *}, since this often allows the
105 C compiler to detect accidental modifications as well as providing some
106 amount of documentation about what your program intends to do with the
107 string.
109 The amount of memory allocated for a byte array may extend past the null byte
110 that marks the end of the string that the array contains.  In this
111 document, the term @dfn{allocated size} is always used to refer to the
112 total amount of memory allocated for an array, while the term
113 @dfn{length} refers to the number of bytes up to (but not including)
114 the terminating null byte.  Wide strings are similar, except their
115 sizes and lengths count wide characters, not bytes.
116 @cindex length of string
117 @cindex allocation size of string
118 @cindex size of string
119 @cindex string length
120 @cindex string allocation
122 A notorious source of program bugs is trying to put more bytes into a
123 string than fit in its allocated size.  When writing code that extends
124 strings or moves bytes into a pre-allocated array, you should be
125 very careful to keep track of the length of the string and make explicit
126 checks for overflowing the array.  Many of the library functions
127 @emph{do not} do this for you!  Remember also that you need to allocate
128 an extra byte to hold the null byte that marks the end of the
129 string.
131 @cindex single-byte string
132 @cindex multibyte string
133 Originally strings were sequences of bytes where each byte represented a
134 single character.  This is still true today if the strings are encoded
135 using a single-byte character encoding.  Things are different if the
136 strings are encoded using a multibyte encoding (for more information on
137 encodings see @ref{Extended Char Intro}).  There is no difference in
138 the programming interface for these two kind of strings; the programmer
139 has to be aware of this and interpret the byte sequences accordingly.
141 But since there is no separate interface taking care of these
142 differences the byte-based string functions are sometimes hard to use.
143 Since the count parameters of these functions specify bytes a call to
144 @code{memcpy} could cut a multibyte character in the middle and put an
145 incomplete (and therefore unusable) byte sequence in the target buffer.
147 @cindex wide string
148 To avoid these problems later versions of the @w{ISO C} standard
149 introduce a second set of functions which are operating on @dfn{wide
150 characters} (@pxref{Extended Char Intro}).  These functions don't have
151 the problems the single-byte versions have since every wide character is
152 a legal, interpretable value.  This does not mean that cutting wide
153 strings at arbitrary points is without problems.  It normally
154 is for alphabet-based languages (except for non-normalized text) but
155 languages based on syllables still have the problem that more than one
156 wide character is necessary to complete a logical unit.  This is a
157 higher level problem which the @w{C library} functions are not designed
158 to solve.  But it is at least good that no invalid byte sequences can be
159 created.  Also, the higher level functions can also much more easily operate
160 on wide characters than on multibyte characters so that a common strategy
161 is to use wide characters internally whenever text is more than simply
162 copied.
164 The remaining of this chapter will discuss the functions for handling
165 wide strings in parallel with the discussion of
166 strings since there is almost always an exact equivalent
167 available.
169 @node String/Array Conventions
170 @section String and Array Conventions
172 This chapter describes both functions that work on arbitrary arrays or
173 blocks of memory, and functions that are specific to strings and wide
174 strings.
176 Functions that operate on arbitrary blocks of memory have names
177 beginning with @samp{mem} and @samp{wmem} (such as @code{memcpy} and
178 @code{wmemcpy}) and invariably take an argument which specifies the size
179 (in bytes and wide characters respectively) of the block of memory to
180 operate on.  The array arguments and return values for these functions
181 have type @code{void *} or @code{wchar_t}.  As a matter of style, the
182 elements of the arrays used with the @samp{mem} functions are referred
183 to as ``bytes''.  You can pass any kind of pointer to these functions,
184 and the @code{sizeof} operator is useful in computing the value for the
185 size argument.  Parameters to the @samp{wmem} functions must be of type
186 @code{wchar_t *}.  These functions are not really usable with anything
187 but arrays of this type.
189 In contrast, functions that operate specifically on strings and wide
190 strings have names beginning with @samp{str} and @samp{wcs}
191 respectively (such as @code{strcpy} and @code{wcscpy}) and look for a
192 terminating null byte or null wide character instead of requiring an explicit
193 size argument to be passed.  (Some of these functions accept a specified
194 maximum length, but they also check for premature termination.)
195 The array arguments and return values for these
196 functions have type @code{char *} and @code{wchar_t *} respectively, and
197 the array elements are referred to as ``bytes'' and ``wide
198 characters''.
200 In many cases, there are both @samp{mem} and @samp{str}/@samp{wcs}
201 versions of a function.  The one that is more appropriate to use depends
202 on the exact situation.  When your program is manipulating arbitrary
203 arrays or blocks of storage, then you should always use the @samp{mem}
204 functions.  On the other hand, when you are manipulating
205 strings it is usually more convenient to use the @samp{str}/@samp{wcs}
206 functions, unless you already know the length of the string in advance.
207 The @samp{wmem} functions should be used for wide character arrays with
208 known size.
210 @cindex wint_t
211 @cindex parameter promotion
212 Some of the memory and string functions take single characters as
213 arguments.  Since a value of type @code{char} is automatically promoted
214 into a value of type @code{int} when used as a parameter, the functions
215 are declared with @code{int} as the type of the parameter in question.
216 In case of the wide character functions the situation is similar: the
217 parameter type for a single wide character is @code{wint_t} and not
218 @code{wchar_t}.  This would for many implementations not be necessary
219 since @code{wchar_t} is large enough to not be automatically
220 promoted, but since the @w{ISO C} standard does not require such a
221 choice of types the @code{wint_t} type is used.
223 @node String Length
224 @section String Length
226 You can get the length of a string using the @code{strlen} function.
227 This function is declared in the header file @file{string.h}.
228 @pindex string.h
230 @deftypefun size_t strlen (const char *@var{s})
231 @standards{ISO, string.h}
232 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
233 The @code{strlen} function returns the length of the
234 string @var{s} in bytes.  (In other words, it returns the offset of the
235 terminating null byte within the array.)
237 For example,
238 @smallexample
239 strlen ("hello, world")
240     @result{} 12
241 @end smallexample
243 When applied to an array, the @code{strlen} function returns
244 the length of the string stored there, not its allocated size.  You can
245 get the allocated size of the array that holds a string using
246 the @code{sizeof} operator:
248 @smallexample
249 char string[32] = "hello, world";
250 sizeof (string)
251     @result{} 32
252 strlen (string)
253     @result{} 12
254 @end smallexample
256 But beware, this will not work unless @var{string} is the
257 array itself, not a pointer to it.  For example:
259 @smallexample
260 char string[32] = "hello, world";
261 char *ptr = string;
262 sizeof (string)
263     @result{} 32
264 sizeof (ptr)
265     @result{} 4  /* @r{(on a machine with 4 byte pointers)} */
266 @end smallexample
268 This is an easy mistake to make when you are working with functions that
269 take string arguments; those arguments are always pointers, not arrays.
271 It must also be noted that for multibyte encoded strings the return
272 value does not have to correspond to the number of characters in the
273 string.  To get this value the string can be converted to wide
274 characters and @code{wcslen} can be used or something like the following
275 code can be used:
277 @smallexample
278 /* @r{The input is in @code{string}.}
279    @r{The length is expected in @code{n}.}  */
281   mbstate_t t;
282   char *scopy = string;
283   /* In initial state.  */
284   memset (&t, '\0', sizeof (t));
285   /* Determine number of characters.  */
286   n = mbsrtowcs (NULL, &scopy, strlen (scopy), &t);
288 @end smallexample
290 This is cumbersome to do so if the number of characters (as opposed to
291 bytes) is needed often it is better to work with wide characters.
292 @end deftypefun
294 The wide character equivalent is declared in @file{wchar.h}.
296 @deftypefun size_t wcslen (const wchar_t *@var{ws})
297 @standards{ISO, wchar.h}
298 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
299 The @code{wcslen} function is the wide character equivalent to
300 @code{strlen}.  The return value is the number of wide characters in the
301 wide string pointed to by @var{ws} (this is also the offset of
302 the terminating null wide character of @var{ws}).
304 Since there are no multi wide character sequences making up one wide
305 character the return value is not only the offset in the array, it is
306 also the number of wide characters.
308 This function was introduced in @w{Amendment 1} to @w{ISO C90}.
309 @end deftypefun
311 @deftypefun size_t strnlen (const char *@var{s}, size_t @var{maxlen})
312 @standards{GNU, string.h}
313 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
314 If the array @var{s} of size @var{maxlen} contains a null byte,
315 the @code{strnlen} function returns the length of the string @var{s} in
316 bytes.  Otherwise it
317 returns @var{maxlen}.  Therefore this function is equivalent to
318 @code{(strlen (@var{s}) < @var{maxlen} ? strlen (@var{s}) : @var{maxlen})}
319 but it
320 is more efficient and works even if @var{s} is not null-terminated so
321 long as @var{maxlen} does not exceed the size of @var{s}'s array.
323 @smallexample
324 char string[32] = "hello, world";
325 strnlen (string, 32)
326     @result{} 12
327 strnlen (string, 5)
328     @result{} 5
329 @end smallexample
331 This function is a GNU extension and is declared in @file{string.h}.
332 @end deftypefun
334 @deftypefun size_t wcsnlen (const wchar_t *@var{ws}, size_t @var{maxlen})
335 @standards{GNU, wchar.h}
336 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
337 @code{wcsnlen} is the wide character equivalent to @code{strnlen}.  The
338 @var{maxlen} parameter specifies the maximum number of wide characters.
340 This function is a GNU extension and is declared in @file{wchar.h}.
341 @end deftypefun
343 @node Copying Strings and Arrays
344 @section Copying Strings and Arrays
346 You can use the functions described in this section to copy the contents
347 of strings, wide strings, and arrays.  The @samp{str} and @samp{mem}
348 functions are declared in @file{string.h} while the @samp{w} functions
349 are declared in @file{wchar.h}.
350 @pindex string.h
351 @pindex wchar.h
352 @cindex copying strings and arrays
353 @cindex string copy functions
354 @cindex array copy functions
355 @cindex concatenating strings
356 @cindex string concatenation functions
358 A helpful way to remember the ordering of the arguments to the functions
359 in this section is that it corresponds to an assignment expression, with
360 the destination array specified to the left of the source array.  Most
361 of these functions return the address of the destination array; a few
362 return the address of the destination's terminating null, or of just
363 past the destination.
365 Most of these functions do not work properly if the source and
366 destination arrays overlap.  For example, if the beginning of the
367 destination array overlaps the end of the source array, the original
368 contents of that part of the source array may get overwritten before it
369 is copied.  Even worse, in the case of the string functions, the null
370 byte marking the end of the string may be lost, and the copy
371 function might get stuck in a loop trashing all the memory allocated to
372 your program.
374 All functions that have problems copying between overlapping arrays are
375 explicitly identified in this manual.  In addition to functions in this
376 section, there are a few others like @code{sprintf} (@pxref{Formatted
377 Output Functions}) and @code{scanf} (@pxref{Formatted Input
378 Functions}).
380 @deftypefun {void *} memcpy (void *restrict @var{to}, const void *restrict @var{from}, size_t @var{size})
381 @standards{ISO, string.h}
382 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
383 The @code{memcpy} function copies @var{size} bytes from the object
384 beginning at @var{from} into the object beginning at @var{to}.  The
385 behavior of this function is undefined if the two arrays @var{to} and
386 @var{from} overlap; use @code{memmove} instead if overlapping is possible.
388 The value returned by @code{memcpy} is the value of @var{to}.
390 Here is an example of how you might use @code{memcpy} to copy the
391 contents of an array:
393 @smallexample
394 struct foo *oldarray, *newarray;
395 int arraysize;
396 @dots{}
397 memcpy (new, old, arraysize * sizeof (struct foo));
398 @end smallexample
399 @end deftypefun
401 @deftypefun {wchar_t *} wmemcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
402 @standards{ISO, wchar.h}
403 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
404 The @code{wmemcpy} function copies @var{size} wide characters from the object
405 beginning at @var{wfrom} into the object beginning at @var{wto}.  The
406 behavior of this function is undefined if the two arrays @var{wto} and
407 @var{wfrom} overlap; use @code{wmemmove} instead if overlapping is possible.
409 The following is a possible implementation of @code{wmemcpy} but there
410 are more optimizations possible.
412 @smallexample
413 wchar_t *
414 wmemcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
415          size_t size)
417   return (wchar_t *) memcpy (wto, wfrom, size * sizeof (wchar_t));
419 @end smallexample
421 The value returned by @code{wmemcpy} is the value of @var{wto}.
423 This function was introduced in @w{Amendment 1} to @w{ISO C90}.
424 @end deftypefun
426 @deftypefun {void *} mempcpy (void *restrict @var{to}, const void *restrict @var{from}, size_t @var{size})
427 @standards{GNU, string.h}
428 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
429 The @code{mempcpy} function is nearly identical to the @code{memcpy}
430 function.  It copies @var{size} bytes from the object beginning at
431 @code{from} into the object pointed to by @var{to}.  But instead of
432 returning the value of @var{to} it returns a pointer to the byte
433 following the last written byte in the object beginning at @var{to}.
434 I.e., the value is @code{((void *) ((char *) @var{to} + @var{size}))}.
436 This function is useful in situations where a number of objects shall be
437 copied to consecutive memory positions.
439 @smallexample
440 void *
441 combine (void *o1, size_t s1, void *o2, size_t s2)
443   void *result = malloc (s1 + s2);
444   if (result != NULL)
445     mempcpy (mempcpy (result, o1, s1), o2, s2);
446   return result;
448 @end smallexample
450 This function is a GNU extension.
451 @end deftypefun
453 @deftypefun {wchar_t *} wmempcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
454 @standards{GNU, wchar.h}
455 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
456 The @code{wmempcpy} function is nearly identical to the @code{wmemcpy}
457 function.  It copies @var{size} wide characters from the object
458 beginning at @code{wfrom} into the object pointed to by @var{wto}.  But
459 instead of returning the value of @var{wto} it returns a pointer to the
460 wide character following the last written wide character in the object
461 beginning at @var{wto}.  I.e., the value is @code{@var{wto} + @var{size}}.
463 This function is useful in situations where a number of objects shall be
464 copied to consecutive memory positions.
466 The following is a possible implementation of @code{wmemcpy} but there
467 are more optimizations possible.
469 @smallexample
470 wchar_t *
471 wmempcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
472           size_t size)
474   return (wchar_t *) mempcpy (wto, wfrom, size * sizeof (wchar_t));
476 @end smallexample
478 This function is a GNU extension.
479 @end deftypefun
481 @deftypefun {void *} memmove (void *@var{to}, const void *@var{from}, size_t @var{size})
482 @standards{ISO, string.h}
483 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
484 @code{memmove} copies the @var{size} bytes at @var{from} into the
485 @var{size} bytes at @var{to}, even if those two blocks of space
486 overlap.  In the case of overlap, @code{memmove} is careful to copy the
487 original values of the bytes in the block at @var{from}, including those
488 bytes which also belong to the block at @var{to}.
490 The value returned by @code{memmove} is the value of @var{to}.
491 @end deftypefun
493 @deftypefun {wchar_t *} wmemmove (wchar_t *@var{wto}, const wchar_t *@var{wfrom}, size_t @var{size})
494 @standards{ISO, wchar.h}
495 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
496 @code{wmemmove} copies the @var{size} wide characters at @var{wfrom}
497 into the @var{size} wide characters at @var{wto}, even if those two
498 blocks of space overlap.  In the case of overlap, @code{wmemmove} is
499 careful to copy the original values of the wide characters in the block
500 at @var{wfrom}, including those wide characters which also belong to the
501 block at @var{wto}.
503 The following is a possible implementation of @code{wmemcpy} but there
504 are more optimizations possible.
506 @smallexample
507 wchar_t *
508 wmempcpy (wchar_t *restrict wto, const wchar_t *restrict wfrom,
509           size_t size)
511   return (wchar_t *) mempcpy (wto, wfrom, size * sizeof (wchar_t));
513 @end smallexample
515 The value returned by @code{wmemmove} is the value of @var{wto}.
517 This function is a GNU extension.
518 @end deftypefun
520 @deftypefun {void *} memccpy (void *restrict @var{to}, const void *restrict @var{from}, int @var{c}, size_t @var{size})
521 @standards{SVID, string.h}
522 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
523 This function copies no more than @var{size} bytes from @var{from} to
524 @var{to}, stopping if a byte matching @var{c} is found.  The return
525 value is a pointer into @var{to} one byte past where @var{c} was copied,
526 or a null pointer if no byte matching @var{c} appeared in the first
527 @var{size} bytes of @var{from}.
528 @end deftypefun
530 @deftypefun {void *} memset (void *@var{block}, int @var{c}, size_t @var{size})
531 @standards{ISO, string.h}
532 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
533 This function copies the value of @var{c} (converted to an
534 @code{unsigned char}) into each of the first @var{size} bytes of the
535 object beginning at @var{block}.  It returns the value of @var{block}.
536 @end deftypefun
538 @deftypefun {wchar_t *} wmemset (wchar_t *@var{block}, wchar_t @var{wc}, size_t @var{size})
539 @standards{ISO, wchar.h}
540 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
541 This function copies the value of @var{wc} into each of the first
542 @var{size} wide characters of the object beginning at @var{block}.  It
543 returns the value of @var{block}.
544 @end deftypefun
546 @deftypefun {char *} strcpy (char *restrict @var{to}, const char *restrict @var{from})
547 @standards{ISO, string.h}
548 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
549 This copies bytes from the string @var{from} (up to and including
550 the terminating null byte) into the string @var{to}.  Like
551 @code{memcpy}, this function has undefined results if the strings
552 overlap.  The return value is the value of @var{to}.
553 @end deftypefun
555 @deftypefun {wchar_t *} wcscpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
556 @standards{ISO, wchar.h}
557 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
558 This copies wide characters from the wide string @var{wfrom} (up to and
559 including the terminating null wide character) into the string
560 @var{wto}.  Like @code{wmemcpy}, this function has undefined results if
561 the strings overlap.  The return value is the value of @var{wto}.
562 @end deftypefun
564 @deftypefun {char *} strdup (const char *@var{s})
565 @standards{SVID, string.h}
566 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
567 This function copies the string @var{s} into a newly
568 allocated string.  The string is allocated using @code{malloc}; see
569 @ref{Unconstrained Allocation}.  If @code{malloc} cannot allocate space
570 for the new string, @code{strdup} returns a null pointer.  Otherwise it
571 returns a pointer to the new string.
572 @end deftypefun
574 @deftypefun {wchar_t *} wcsdup (const wchar_t *@var{ws})
575 @standards{GNU, wchar.h}
576 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
577 This function copies the wide string @var{ws}
578 into a newly allocated string.  The string is allocated using
579 @code{malloc}; see @ref{Unconstrained Allocation}.  If @code{malloc}
580 cannot allocate space for the new string, @code{wcsdup} returns a null
581 pointer.  Otherwise it returns a pointer to the new wide string.
583 This function is a GNU extension.
584 @end deftypefun
586 @deftypefun {char *} stpcpy (char *restrict @var{to}, const char *restrict @var{from})
587 @standards{Unknown origin, string.h}
588 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
589 This function is like @code{strcpy}, except that it returns a pointer to
590 the end of the string @var{to} (that is, the address of the terminating
591 null byte @code{to + strlen (from)}) rather than the beginning.
593 For example, this program uses @code{stpcpy} to concatenate @samp{foo}
594 and @samp{bar} to produce @samp{foobar}, which it then prints.
596 @smallexample
597 @include stpcpy.c.texi
598 @end smallexample
600 This function is part of POSIX.1-2008 and later editions, but was
601 available in @theglibc{} and other systems as an extension long before
602 it was standardized.
604 Its behavior is undefined if the strings overlap.  The function is
605 declared in @file{string.h}.
606 @end deftypefun
608 @deftypefun {wchar_t *} wcpcpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
609 @standards{GNU, wchar.h}
610 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
611 This function is like @code{wcscpy}, except that it returns a pointer to
612 the end of the string @var{wto} (that is, the address of the terminating
613 null wide character @code{wto + wcslen (wfrom)}) rather than the beginning.
615 This function is not part of ISO or POSIX but was found useful while
616 developing @theglibc{} itself.
618 The behavior of @code{wcpcpy} is undefined if the strings overlap.
620 @code{wcpcpy} is a GNU extension and is declared in @file{wchar.h}.
621 @end deftypefun
623 @deftypefn {Macro} {char *} strdupa (const char *@var{s})
624 @standards{GNU, string.h}
625 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
626 This macro is similar to @code{strdup} but allocates the new string
627 using @code{alloca} instead of @code{malloc} (@pxref{Variable Size
628 Automatic}).  This means of course the returned string has the same
629 limitations as any block of memory allocated using @code{alloca}.
631 For obvious reasons @code{strdupa} is implemented only as a macro;
632 you cannot get the address of this function.  Despite this limitation
633 it is a useful function.  The following code shows a situation where
634 using @code{malloc} would be a lot more expensive.
636 @smallexample
637 @include strdupa.c.texi
638 @end smallexample
640 Please note that calling @code{strtok} using @var{path} directly is
641 invalid.  It is also not allowed to call @code{strdupa} in the argument
642 list of @code{strtok} since @code{strdupa} uses @code{alloca}
643 (@pxref{Variable Size Automatic}) can interfere with the parameter
644 passing.
646 This function is only available if GNU CC is used.
647 @end deftypefn
649 @deftypefun void bcopy (const void *@var{from}, void *@var{to}, size_t @var{size})
650 @standards{BSD, string.h}
651 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
652 This is a partially obsolete alternative for @code{memmove}, derived from
653 BSD.  Note that it is not quite equivalent to @code{memmove}, because the
654 arguments are not in the same order and there is no return value.
655 @end deftypefun
657 @deftypefun void bzero (void *@var{block}, size_t @var{size})
658 @standards{BSD, string.h}
659 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
660 This is a partially obsolete alternative for @code{memset}, derived from
661 BSD.  Note that it is not as general as @code{memset}, because the only
662 value it can store is zero.
663 @end deftypefun
665 @node Concatenating Strings
666 @section Concatenating Strings
667 @pindex string.h
668 @pindex wchar.h
669 @cindex concatenating strings
670 @cindex string concatenation functions
672 The functions described in this section concatenate the contents of a
673 string or wide string to another.  They follow the string-copying
674 functions in their conventions.  @xref{Copying Strings and Arrays}.
675 @samp{strcat} is declared in the header file @file{string.h} while
676 @samp{wcscat} is declared in @file{wchar.h}.
678 As noted below, these functions are problematic as their callers may
679 have performance issues.
681 @deftypefun {char *} strcat (char *restrict @var{to}, const char *restrict @var{from})
682 @standards{ISO, string.h}
683 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
684 The @code{strcat} function is similar to @code{strcpy}, except that the
685 bytes from @var{from} are concatenated or appended to the end of
686 @var{to}, instead of overwriting it.  That is, the first byte from
687 @var{from} overwrites the null byte marking the end of @var{to}.
689 An equivalent definition for @code{strcat} would be:
691 @smallexample
692 char *
693 strcat (char *restrict to, const char *restrict from)
695   strcpy (to + strlen (to), from);
696   return to;
698 @end smallexample
700 This function has undefined results if the strings overlap.
702 As noted below, this function has significant performance issues.
703 @end deftypefun
705 @deftypefun {wchar_t *} wcscat (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom})
706 @standards{ISO, wchar.h}
707 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
708 The @code{wcscat} function is similar to @code{wcscpy}, except that the
709 wide characters from @var{wfrom} are concatenated or appended to the end of
710 @var{wto}, instead of overwriting it.  That is, the first wide character from
711 @var{wfrom} overwrites the null wide character marking the end of @var{wto}.
713 An equivalent definition for @code{wcscat} would be:
715 @smallexample
716 wchar_t *
717 wcscat (wchar_t *wto, const wchar_t *wfrom)
719   wcscpy (wto + wcslen (wto), wfrom);
720   return wto;
722 @end smallexample
724 This function has undefined results if the strings overlap.
726 As noted below, this function has significant performance issues.
727 @end deftypefun
729 Programmers using the @code{strcat} or @code{wcscat} function (or the
730 @code{strncat} or @code{wcsncat} functions defined in
731 a later section, for that matter)
732 can easily be recognized as lazy and reckless.  In almost all situations
733 the lengths of the participating strings are known (it better should be
734 since how can one otherwise ensure the allocated size of the buffer is
735 sufficient?)  Or at least, one could know them if one keeps track of the
736 results of the various function calls.  But then it is very inefficient
737 to use @code{strcat}/@code{wcscat}.  A lot of time is wasted finding the
738 end of the destination string so that the actual copying can start.
739 This is a common example:
741 @cindex va_copy
742 @smallexample
743 /* @r{This function concatenates arbitrarily many strings.  The last}
744    @r{parameter must be @code{NULL}.}  */
745 char *
746 concat (const char *str, @dots{})
748   va_list ap, ap2;
749   size_t total = 1;
751   va_start (ap, str);
752   va_copy (ap2, ap);
754   /* @r{Determine how much space we need.}  */
755   for (const char *s = str; s != NULL; s = va_arg (ap, const char *))
756     total += strlen (s);
758   va_end (ap);
760   char *result = malloc (total);
761   if (result != NULL)
762     @{
763       result[0] = '\0';
765       /* @r{Copy the strings.}  */
766       for (s = str; s != NULL; s = va_arg (ap2, const char *))
767         strcat (result, s);
768     @}
770   va_end (ap2);
772   return result;
774 @end smallexample
776 This looks quite simple, especially the second loop where the strings
777 are actually copied.  But these innocent lines hide a major performance
778 penalty.  Just imagine that ten strings of 100 bytes each have to be
779 concatenated.  For the second string we search the already stored 100
780 bytes for the end of the string so that we can append the next string.
781 For all strings in total the comparisons necessary to find the end of
782 the intermediate results sums up to 5500!  If we combine the copying
783 with the search for the allocation we can write this function more
784 efficiently:
786 @smallexample
787 char *
788 concat (const char *str, @dots{})
790   size_t allocated = 100;
791   char *result = malloc (allocated);
793   if (result != NULL)
794     @{
795       va_list ap;
796       size_t resultlen = 0;
797       char *newp;
799       va_start (ap, str);
801       for (const char *s = str; s != NULL; s = va_arg (ap, const char *))
802         @{
803           size_t len = strlen (s);
805           /* @r{Resize the allocated memory if necessary.}  */
806           if (resultlen + len + 1 > allocated)
807             @{
808               allocated += len;
809               newp = reallocarray (result, allocated, 2);
810               allocated *= 2;
811               if (newp == NULL)
812                 @{
813                   free (result);
814                   return NULL;
815                 @}
816               result = newp;
817             @}
819           memcpy (result + resultlen, s, len);
820           resultlen += len;
821         @}
823       /* @r{Terminate the result string.}  */
824       result[resultlen++] = '\0';
826       /* @r{Resize memory to the optimal size.}  */
827       newp = realloc (result, resultlen);
828       if (newp != NULL)
829         result = newp;
831       va_end (ap);
832     @}
834   return result;
836 @end smallexample
838 With a bit more knowledge about the input strings one could fine-tune
839 the memory allocation.  The difference we are pointing to here is that
840 we don't use @code{strcat} anymore.  We always keep track of the length
841 of the current intermediate result so we can save ourselves the search for the
842 end of the string and use @code{mempcpy}.  Please note that we also
843 don't use @code{stpcpy} which might seem more natural since we are handling
844 strings.  But this is not necessary since we already know the
845 length of the string and therefore can use the faster memory copying
846 function.  The example would work for wide characters the same way.
848 Whenever a programmer feels the need to use @code{strcat} she or he
849 should think twice and look through the program to see whether the code cannot
850 be rewritten to take advantage of already calculated results.
851 The related functions @code{strncat} and @code{wcscat}
852 are almost always unnecessary, too.
853 Again: it is almost always unnecessary to use functions like @code{strcat}.
855 @node Truncating Strings
856 @section Truncating Strings while Copying
857 @cindex truncating strings
858 @cindex string truncation
860 The functions described in this section copy or concatenate the
861 possibly-truncated contents of a string or array to another, and
862 similarly for wide strings.  They follow the string-copying functions
863 in their header conventions.  @xref{Copying Strings and Arrays}.  The
864 @samp{str} functions are declared in the header file @file{string.h}
865 and the @samp{wc} functions are declared in the file @file{wchar.h}.
867 As noted below, these functions are problematic as their callers may
868 have truncation-related bugs and performance issues.
870 @deftypefun {char *} strncpy (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
871 @standards{C90, string.h}
872 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
873 This function is similar to @code{strcpy} but always copies exactly
874 @var{size} bytes into @var{to}.
876 If @var{from} does not contain a null byte in its first @var{size}
877 bytes, @code{strncpy} copies just the first @var{size} bytes.  In this
878 case no null terminator is written into @var{to}.
880 Otherwise @var{from} must be a string with length less than
881 @var{size}.  In this case @code{strncpy} copies all of @var{from},
882 followed by enough null bytes to add up to @var{size} bytes in all.
884 The behavior of @code{strncpy} is undefined if the strings overlap.
886 This function was designed for now-rarely-used arrays consisting of
887 non-null bytes followed by zero or more null bytes.  It needs to set
888 all @var{size} bytes of the destination, even when @var{size} is much
889 greater than the length of @var{from}.  As noted below, this function
890 is generally a poor choice for processing strings.
891 @end deftypefun
893 @deftypefun {wchar_t *} wcsncpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
894 @standards{ISO, wchar.h}
895 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
896 This function is similar to @code{wcscpy} but always copies exactly
897 @var{size} wide characters into @var{wto}.
899 If @var{wfrom} does not contain a null wide character in its first
900 @var{size} wide characters, then @code{wcsncpy} copies just the first
901 @var{size} wide characters.  In this case no null terminator is
902 written into @var{wto}.
904 Otherwise @var{wfrom} must be a wide string with length less than
905 @var{size}.  In this case @code{wcsncpy} copies all of @var{wfrom},
906 followed by enough null wide characters to add up to @var{size} wide
907 characters in all.
909 The behavior of @code{wcsncpy} is undefined if the strings overlap.
911 This function is the wide-character counterpart of @code{strncpy} and
912 suffers from most of the problems that @code{strncpy} does.  For
913 example, as noted below, this function is generally a poor choice for
914 processing strings.
915 @end deftypefun
917 @deftypefun {char *} strndup (const char *@var{s}, size_t @var{size})
918 @standards{GNU, string.h}
919 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
920 This function is similar to @code{strdup} but always copies at most
921 @var{size} bytes into the newly allocated string.
923 If the length of @var{s} is more than @var{size}, then @code{strndup}
924 copies just the first @var{size} bytes and adds a closing null byte.
925 Otherwise all bytes are copied and the string is terminated.
927 This function differs from @code{strncpy} in that it always terminates
928 the destination string.
930 As noted below, this function is generally a poor choice for
931 processing strings.
933 @code{strndup} is a GNU extension.
934 @end deftypefun
936 @deftypefn {Macro} {char *} strndupa (const char *@var{s}, size_t @var{size})
937 @standards{GNU, string.h}
938 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
939 This function is similar to @code{strndup} but like @code{strdupa} it
940 allocates the new string using @code{alloca} @pxref{Variable Size
941 Automatic}.  The same advantages and limitations of @code{strdupa} are
942 valid for @code{strndupa}, too.
944 This function is implemented only as a macro, just like @code{strdupa}.
945 Just as @code{strdupa} this macro also must not be used inside the
946 parameter list in a function call.
948 As noted below, this function is generally a poor choice for
949 processing strings.
951 @code{strndupa} is only available if GNU CC is used.
952 @end deftypefn
954 @deftypefun {char *} stpncpy (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
955 @standards{GNU, string.h}
956 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
957 This function is similar to @code{stpcpy} but copies always exactly
958 @var{size} bytes into @var{to}.
960 If the length of @var{from} is more than @var{size}, then @code{stpncpy}
961 copies just the first @var{size} bytes and returns a pointer to the
962 byte directly following the one which was copied last.  Note that in
963 this case there is no null terminator written into @var{to}.
965 If the length of @var{from} is less than @var{size}, then @code{stpncpy}
966 copies all of @var{from}, followed by enough null bytes to add up
967 to @var{size} bytes in all.  This behavior is rarely useful, but it
968 is implemented to be useful in contexts where this behavior of the
969 @code{strncpy} is used.  @code{stpncpy} returns a pointer to the
970 @emph{first} written null byte.
972 This function is not part of ISO or POSIX but was found useful while
973 developing @theglibc{} itself.
975 Its behavior is undefined if the strings overlap.  The function is
976 declared in @file{string.h}.
978 As noted below, this function is generally a poor choice for
979 processing strings.
980 @end deftypefun
982 @deftypefun {wchar_t *} wcpncpy (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
983 @standards{GNU, wchar.h}
984 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
985 This function is similar to @code{wcpcpy} but copies always exactly
986 @var{wsize} wide characters into @var{wto}.
988 If the length of @var{wfrom} is more than @var{size}, then
989 @code{wcpncpy} copies just the first @var{size} wide characters and
990 returns a pointer to the wide character directly following the last
991 non-null wide character which was copied last.  Note that in this case
992 there is no null terminator written into @var{wto}.
994 If the length of @var{wfrom} is less than @var{size}, then @code{wcpncpy}
995 copies all of @var{wfrom}, followed by enough null wide characters to add up
996 to @var{size} wide characters in all.  This behavior is rarely useful, but it
997 is implemented to be useful in contexts where this behavior of the
998 @code{wcsncpy} is used.  @code{wcpncpy} returns a pointer to the
999 @emph{first} written null wide character.
1001 This function is not part of ISO or POSIX but was found useful while
1002 developing @theglibc{} itself.
1004 Its behavior is undefined if the strings overlap.
1006 As noted below, this function is generally a poor choice for
1007 processing strings.
1009 @code{wcpncpy} is a GNU extension.
1010 @end deftypefun
1012 @deftypefun {char *} strncat (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
1013 @standards{ISO, string.h}
1014 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1015 This function is like @code{strcat} except that not more than @var{size}
1016 bytes from @var{from} are appended to the end of @var{to}, and
1017 @var{from} need not be null-terminated.  A single null byte is also
1018 always appended to @var{to}, so the total
1019 allocated size of @var{to} must be at least @code{@var{size} + 1} bytes
1020 longer than its initial length.
1022 The @code{strncat} function could be implemented like this:
1024 @smallexample
1025 @group
1026 char *
1027 strncat (char *to, const char *from, size_t size)
1029   size_t len = strlen (to);
1030   memcpy (to + len, from, strnlen (from, size));
1031   to[len + strnlen (from, size)] = '\0';
1032   return to;
1034 @end group
1035 @end smallexample
1037 The behavior of @code{strncat} is undefined if the strings overlap.
1039 As a companion to @code{strncpy}, @code{strncat} was designed for
1040 now-rarely-used arrays consisting of non-null bytes followed by zero
1041 or more null bytes.  As noted below, this function is generally a poor
1042 choice for processing strings.  Also, this function has significant
1043 performance issues.  @xref{Concatenating Strings}.
1044 @end deftypefun
1046 @deftypefun {wchar_t *} wcsncat (wchar_t *restrict @var{wto}, const wchar_t *restrict @var{wfrom}, size_t @var{size})
1047 @standards{ISO, wchar.h}
1048 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1049 This function is like @code{wcscat} except that not more than @var{size}
1050 wide characters from @var{from} are appended to the end of @var{to},
1051 and @var{from} need not be null-terminated.  A single null wide
1052 character is also always appended to @var{to}, so the total allocated
1053 size of @var{to} must be at least @code{wcsnlen (@var{wfrom},
1054 @var{size}) + 1} wide characters longer than its initial length.
1056 The @code{wcsncat} function could be implemented like this:
1058 @smallexample
1059 @group
1060 wchar_t *
1061 wcsncat (wchar_t *restrict wto, const wchar_t *restrict wfrom,
1062          size_t size)
1064   size_t len = wcslen (wto);
1065   memcpy (wto + len, wfrom, wcsnlen (wfrom, size) * sizeof (wchar_t));
1066   wto[len + wcsnlen (wfrom, size)] = L'\0';
1067   return wto;
1069 @end group
1070 @end smallexample
1072 The behavior of @code{wcsncat} is undefined if the strings overlap.
1074 As noted below, this function is generally a poor choice for
1075 processing strings.  Also, this function has significant performance
1076 issues.  @xref{Concatenating Strings}.
1077 @end deftypefun
1079 Because these functions can abruptly truncate strings or wide strings,
1080 they are generally poor choices for processing them.  When copying or
1081 concatening multibyte strings, they can truncate within a multibyte
1082 character so that the result is not a valid multibyte string.  When
1083 combining or concatenating multibyte or wide strings, they may
1084 truncate the output after a combining character, resulting in a
1085 corrupted grapheme.  They can cause bugs even when processing
1086 single-byte strings: for example, when calculating an ASCII-only user
1087 name, a truncated name can identify the wrong user.
1089 Although some buffer overruns can be prevented by manually replacing
1090 calls to copying functions with calls to truncation functions, there
1091 are often easier and safer automatic techniques, such as fortification
1092 (@pxref{Source Fortification}) and AddressSanitizer
1093 (@pxref{Instrumentation Options,, Program Instrumentation Options, gcc, Using GCC}).
1094 Because truncation functions can mask
1095 application bugs that would otherwise be caught by the automatic
1096 techniques, these functions should be used only when the application's
1097 underlying logic requires truncation.
1099 @strong{Note:} GNU programs should not truncate strings or wide
1100 strings to fit arbitrary size limits.  @xref{Semantics, , Writing
1101 Robust Programs, standards, The GNU Coding Standards}.  Instead of
1102 string-truncation functions, it is usually better to use dynamic
1103 memory allocation (@pxref{Unconstrained Allocation}) and functions
1104 such as @code{strdup} or @code{asprintf} to construct strings.
1106 @node String/Array Comparison
1107 @section String/Array Comparison
1108 @cindex comparing strings and arrays
1109 @cindex string comparison functions
1110 @cindex array comparison functions
1111 @cindex predicates on strings
1112 @cindex predicates on arrays
1114 You can use the functions in this section to perform comparisons on the
1115 contents of strings and arrays.  As well as checking for equality, these
1116 functions can also be used as the ordering functions for sorting
1117 operations.  @xref{Searching and Sorting}, for an example of this.
1119 Unlike most comparison operations in C, the string comparison functions
1120 return a nonzero value if the strings are @emph{not} equivalent rather
1121 than if they are.  The sign of the value indicates the relative ordering
1122 of the first part of the strings that are not equivalent:  a
1123 negative value indicates that the first string is ``less'' than the
1124 second, while a positive value indicates that the first string is
1125 ``greater''.
1127 The most common use of these functions is to check only for equality.
1128 This is canonically done with an expression like @w{@samp{! strcmp (s1, s2)}}.
1130 All of these functions are declared in the header file @file{string.h}.
1131 @pindex string.h
1133 @deftypefun int memcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
1134 @standards{ISO, string.h}
1135 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1136 The function @code{memcmp} compares the @var{size} bytes of memory
1137 beginning at @var{a1} against the @var{size} bytes of memory beginning
1138 at @var{a2}.  The value returned has the same sign as the difference
1139 between the first differing pair of bytes (interpreted as @code{unsigned
1140 char} objects, then promoted to @code{int}).
1142 If the contents of the two blocks are equal, @code{memcmp} returns
1143 @code{0}.
1144 @end deftypefun
1146 @deftypefun int wmemcmp (const wchar_t *@var{a1}, const wchar_t *@var{a2}, size_t @var{size})
1147 @standards{ISO, wchar.h}
1148 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1149 The function @code{wmemcmp} compares the @var{size} wide characters
1150 beginning at @var{a1} against the @var{size} wide characters beginning
1151 at @var{a2}.  The value returned is smaller than or larger than zero
1152 depending on whether the first differing wide character is @var{a1} is
1153 smaller or larger than the corresponding wide character in @var{a2}.
1155 If the contents of the two blocks are equal, @code{wmemcmp} returns
1156 @code{0}.
1157 @end deftypefun
1159 On arbitrary arrays, the @code{memcmp} function is mostly useful for
1160 testing equality.  It usually isn't meaningful to do byte-wise ordering
1161 comparisons on arrays of things other than bytes.  For example, a
1162 byte-wise comparison on the bytes that make up floating-point numbers
1163 isn't likely to tell you anything about the relationship between the
1164 values of the floating-point numbers.
1166 @code{wmemcmp} is really only useful to compare arrays of type
1167 @code{wchar_t} since the function looks at @code{sizeof (wchar_t)} bytes
1168 at a time and this number of bytes is system dependent.
1170 You should also be careful about using @code{memcmp} to compare objects
1171 that can contain ``holes'', such as the padding inserted into structure
1172 objects to enforce alignment requirements, extra space at the end of
1173 unions, and extra bytes at the ends of strings whose length is less
1174 than their allocated size.  The contents of these ``holes'' are
1175 indeterminate and may cause strange behavior when performing byte-wise
1176 comparisons.  For more predictable results, perform an explicit
1177 component-wise comparison.
1179 For example, given a structure type definition like:
1181 @smallexample
1182 struct foo
1183   @{
1184     unsigned char tag;
1185     union
1186       @{
1187         double f;
1188         long i;
1189         char *p;
1190       @} value;
1191   @};
1192 @end smallexample
1194 @noindent
1195 you are better off writing a specialized comparison function to compare
1196 @code{struct foo} objects instead of comparing them with @code{memcmp}.
1198 @deftypefun int strcmp (const char *@var{s1}, const char *@var{s2})
1199 @standards{ISO, string.h}
1200 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1201 The @code{strcmp} function compares the string @var{s1} against
1202 @var{s2}, returning a value that has the same sign as the difference
1203 between the first differing pair of bytes (interpreted as
1204 @code{unsigned char} objects, then promoted to @code{int}).
1206 If the two strings are equal, @code{strcmp} returns @code{0}.
1208 A consequence of the ordering used by @code{strcmp} is that if @var{s1}
1209 is an initial substring of @var{s2}, then @var{s1} is considered to be
1210 ``less than'' @var{s2}.
1212 @code{strcmp} does not take sorting conventions of the language the
1213 strings are written in into account.  To get that one has to use
1214 @code{strcoll}.
1215 @end deftypefun
1217 @deftypefun int wcscmp (const wchar_t *@var{ws1}, const wchar_t *@var{ws2})
1218 @standards{ISO, wchar.h}
1219 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1221 The @code{wcscmp} function compares the wide string @var{ws1}
1222 against @var{ws2}.  The value returned is smaller than or larger than zero
1223 depending on whether the first differing wide character is @var{ws1} is
1224 smaller or larger than the corresponding wide character in @var{ws2}.
1226 If the two strings are equal, @code{wcscmp} returns @code{0}.
1228 A consequence of the ordering used by @code{wcscmp} is that if @var{ws1}
1229 is an initial substring of @var{ws2}, then @var{ws1} is considered to be
1230 ``less than'' @var{ws2}.
1232 @code{wcscmp} does not take sorting conventions of the language the
1233 strings are written in into account.  To get that one has to use
1234 @code{wcscoll}.
1235 @end deftypefun
1237 @deftypefun int strcasecmp (const char *@var{s1}, const char *@var{s2})
1238 @standards{BSD, string.h}
1239 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1240 @c Although this calls tolower multiple times, it's a macro, and
1241 @c strcasecmp is optimized so that the locale pointer is read only once.
1242 @c There are some asm implementations too, for which the single-read
1243 @c from locale TLS pointers also applies.
1244 This function is like @code{strcmp}, except that differences in case are
1245 ignored, and its arguments must be multibyte strings.
1246 How uppercase and lowercase characters are related is
1247 determined by the currently selected locale.  In the standard @code{"C"}
1248 locale the characters @"A and @"a do not match but in a locale which
1249 regards these characters as parts of the alphabet they do match.
1251 @noindent
1252 @code{strcasecmp} is derived from BSD.
1253 @end deftypefun
1255 @deftypefun int wcscasecmp (const wchar_t *@var{ws1}, const wchar_t *@var{ws2})
1256 @standards{GNU, wchar.h}
1257 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1258 @c Since towlower is not a macro, the locale object may be read multiple
1259 @c times.
1260 This function is like @code{wcscmp}, except that differences in case are
1261 ignored.  How uppercase and lowercase characters are related is
1262 determined by the currently selected locale.  In the standard @code{"C"}
1263 locale the characters @"A and @"a do not match but in a locale which
1264 regards these characters as parts of the alphabet they do match.
1266 @noindent
1267 @code{wcscasecmp} is a GNU extension.
1268 @end deftypefun
1270 @deftypefun int strncmp (const char *@var{s1}, const char *@var{s2}, size_t @var{size})
1271 @standards{ISO, string.h}
1272 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1273 This function is the similar to @code{strcmp}, except that no more than
1274 @var{size} bytes are compared.  In other words, if the two
1275 strings are the same in their first @var{size} bytes, the
1276 return value is zero.
1277 @end deftypefun
1279 @deftypefun int wcsncmp (const wchar_t *@var{ws1}, const wchar_t *@var{ws2}, size_t @var{size})
1280 @standards{ISO, wchar.h}
1281 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1282 This function is similar to @code{wcscmp}, except that no more than
1283 @var{size} wide characters are compared.  In other words, if the two
1284 strings are the same in their first @var{size} wide characters, the
1285 return value is zero.
1286 @end deftypefun
1288 @deftypefun int strncasecmp (const char *@var{s1}, const char *@var{s2}, size_t @var{n})
1289 @standards{BSD, string.h}
1290 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1291 This function is like @code{strncmp}, except that differences in case
1292 are ignored, and the compared parts of the arguments should consist of
1293 valid multibyte characters.
1294 Like @code{strcasecmp}, it is locale dependent how
1295 uppercase and lowercase characters are related.
1297 @noindent
1298 @code{strncasecmp} is a GNU extension.
1299 @end deftypefun
1301 @deftypefun int wcsncasecmp (const wchar_t *@var{ws1}, const wchar_t *@var{s2}, size_t @var{n})
1302 @standards{GNU, wchar.h}
1303 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1304 This function is like @code{wcsncmp}, except that differences in case
1305 are ignored.  Like @code{wcscasecmp}, it is locale dependent how
1306 uppercase and lowercase characters are related.
1308 @noindent
1309 @code{wcsncasecmp} is a GNU extension.
1310 @end deftypefun
1312 Here are some examples showing the use of @code{strcmp} and
1313 @code{strncmp} (equivalent examples can be constructed for the wide
1314 character functions).  These examples assume the use of the ASCII
1315 character set.  (If some other character set---say, EBCDIC---is used
1316 instead, then the glyphs are associated with different numeric codes,
1317 and the return values and ordering may differ.)
1319 @smallexample
1320 strcmp ("hello", "hello")
1321     @result{} 0    /* @r{These two strings are the same.} */
1322 strcmp ("hello", "Hello")
1323     @result{} 32   /* @r{Comparisons are case-sensitive.} */
1324 strcmp ("hello", "world")
1325     @result{} -15  /* @r{The byte @code{'h'} comes before @code{'w'}.} */
1326 strcmp ("hello", "hello, world")
1327     @result{} -44  /* @r{Comparing a null byte against a comma.} */
1328 strncmp ("hello", "hello, world", 5)
1329     @result{} 0    /* @r{The initial 5 bytes are the same.} */
1330 strncmp ("hello, world", "hello, stupid world!!!", 5)
1331     @result{} 0    /* @r{The initial 5 bytes are the same.} */
1332 @end smallexample
1334 @deftypefun int strverscmp (const char *@var{s1}, const char *@var{s2})
1335 @standards{GNU, string.h}
1336 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1337 @c Calls isdigit multiple times, locale may change in between.
1338 The @code{strverscmp} function compares the string @var{s1} against
1339 @var{s2}, considering them as holding indices/version numbers.  The
1340 return value follows the same conventions as found in the
1341 @code{strcmp} function.  In fact, if @var{s1} and @var{s2} contain no
1342 digits, @code{strverscmp} behaves like @code{strcmp}
1343 (in the sense that the sign of the result is the same).
1345 The comparison algorithm which the @code{strverscmp} function implements
1346 differs slightly from other version-comparison algorithms.  The
1347 implementation is based on a finite-state machine, whose behavior is
1348 approximated below.
1350 @itemize @bullet
1351 @item
1352 The input strings are each split into sequences of non-digits and
1353 digits.  These sequences can be empty at the beginning and end of the
1354 string.  Digits are determined by the @code{isdigit} function and are
1355 thus subject to the current locale.
1357 @item
1358 Comparison starts with a (possibly empty) non-digit sequence.  The first
1359 non-equal sequences of non-digits or digits determines the outcome of
1360 the comparison.
1362 @item
1363 Corresponding non-digit sequences in both strings are compared
1364 lexicographically if their lengths are equal.  If the lengths differ,
1365 the shorter non-digit sequence is extended with the input string
1366 character immediately following it (which may be the null terminator),
1367 the other sequence is truncated to be of the same (extended) length, and
1368 these two sequences are compared lexicographically.  In the last case,
1369 the sequence comparison determines the result of the function because
1370 the extension character (or some character before it) is necessarily
1371 different from the character at the same offset in the other input
1372 string.
1374 @item
1375 For two sequences of digits, the number of leading zeros is counted (which
1376 can be zero).  If the count differs, the string with more leading zeros
1377 in the digit sequence is considered smaller than the other string.
1379 @item
1380 If the two sequences of digits have no leading zeros, they are compared
1381 as integers, that is, the string with the longer digit sequence is
1382 deemed larger, and if both sequences are of equal length, they are
1383 compared lexicographically.
1385 @item
1386 If both digit sequences start with a zero and have an equal number of
1387 leading zeros, they are compared lexicographically if their lengths are
1388 the same.  If the lengths differ, the shorter sequence is extended with
1389 the following character in its input string, and the other sequence is
1390 truncated to the same length, and both sequences are compared
1391 lexicographically (similar to the non-digit sequence case above).
1392 @end itemize
1394 The treatment of leading zeros and the tie-breaking extension characters
1395 (which in effect propagate across non-digit/digit sequence boundaries)
1396 differs from other version-comparison algorithms.
1398 @smallexample
1399 strverscmp ("no digit", "no digit")
1400     @result{} 0    /* @r{same behavior as strcmp.} */
1401 strverscmp ("item#99", "item#100")
1402     @result{} <0   /* @r{same prefix, but 99 < 100.} */
1403 strverscmp ("alpha1", "alpha001")
1404     @result{} >0   /* @r{different number of leading zeros (0 and 2).} */
1405 strverscmp ("part1_f012", "part1_f01")
1406     @result{} >0   /* @r{lexicographical comparison with leading zeros.} */
1407 strverscmp ("foo.009", "foo.0")
1408     @result{} <0   /* @r{different number of leading zeros (2 and 1).} */
1409 @end smallexample
1411 @code{strverscmp} is a GNU extension.
1412 @end deftypefun
1414 @deftypefun int bcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
1415 @standards{BSD, string.h}
1416 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1417 This is an obsolete alias for @code{memcmp}, derived from BSD.
1418 @end deftypefun
1420 @node Collation Functions
1421 @section Collation Functions
1423 @cindex collating strings
1424 @cindex string collation functions
1426 In some locales, the conventions for lexicographic ordering differ from
1427 the strict numeric ordering of character codes.  For example, in Spanish
1428 most glyphs with diacritical marks such as accents are not considered
1429 distinct letters for the purposes of collation.  On the other hand, in
1430 Czech the two-character sequence @samp{ch} is treated as a single letter
1431 that is collated between @samp{h} and @samp{i}.
1433 You can use the functions @code{strcoll} and @code{strxfrm} (declared in
1434 the headers file @file{string.h}) and @code{wcscoll} and @code{wcsxfrm}
1435 (declared in the headers file @file{wchar}) to compare strings using a
1436 collation ordering appropriate for the current locale.  The locale used
1437 by these functions in particular can be specified by setting the locale
1438 for the @code{LC_COLLATE} category; see @ref{Locales}.
1439 @pindex string.h
1440 @pindex wchar.h
1442 In the standard C locale, the collation sequence for @code{strcoll} is
1443 the same as that for @code{strcmp}.  Similarly, @code{wcscoll} and
1444 @code{wcscmp} are the same in this situation.
1446 Effectively, the way these functions work is by applying a mapping to
1447 transform the characters in a multibyte string to a byte
1448 sequence that represents
1449 the string's position in the collating sequence of the current locale.
1450 Comparing two such byte sequences in a simple fashion is equivalent to
1451 comparing the strings with the locale's collating sequence.
1453 The functions @code{strcoll} and @code{wcscoll} perform this translation
1454 implicitly, in order to do one comparison.  By contrast, @code{strxfrm}
1455 and @code{wcsxfrm} perform the mapping explicitly.  If you are making
1456 multiple comparisons using the same string or set of strings, it is
1457 likely to be more efficient to use @code{strxfrm} or @code{wcsxfrm} to
1458 transform all the strings just once, and subsequently compare the
1459 transformed strings with @code{strcmp} or @code{wcscmp}.
1461 @deftypefun int strcoll (const char *@var{s1}, const char *@var{s2})
1462 @standards{ISO, string.h}
1463 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1464 @c Calls strcoll_l with the current locale, which dereferences only the
1465 @c LC_COLLATE data pointer.
1466 The @code{strcoll} function is similar to @code{strcmp} but uses the
1467 collating sequence of the current locale for collation (the
1468 @code{LC_COLLATE} locale).  The arguments are multibyte strings.
1469 @end deftypefun
1471 @deftypefun int wcscoll (const wchar_t *@var{ws1}, const wchar_t *@var{ws2})
1472 @standards{ISO, wchar.h}
1473 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1474 @c Same as strcoll, but calling wcscoll_l.
1475 The @code{wcscoll} function is similar to @code{wcscmp} but uses the
1476 collating sequence of the current locale for collation (the
1477 @code{LC_COLLATE} locale).
1478 @end deftypefun
1480 Here is an example of sorting an array of strings, using @code{strcoll}
1481 to compare them.  The actual sort algorithm is not written here; it
1482 comes from @code{qsort} (@pxref{Array Sort Function}).  The job of the
1483 code shown here is to say how to compare the strings while sorting them.
1484 (Later on in this section, we will show a way to do this more
1485 efficiently using @code{strxfrm}.)
1487 @smallexample
1488 /* @r{This is the comparison function used with @code{qsort}.} */
1491 compare_elements (const void *v1, const void *v2)
1493   char * const *p1 = v1;
1494   char * const *p2 = v2;
1496   return strcoll (*p1, *p2);
1499 /* @r{This is the entry point---the function to sort}
1500    @r{strings using the locale's collating sequence.} */
1502 void
1503 sort_strings (char **array, int nstrings)
1505   /* @r{Sort @code{temp_array} by comparing the strings.} */
1506   qsort (array, nstrings,
1507          sizeof (char *), compare_elements);
1509 @end smallexample
1511 @cindex converting string to collation order
1512 @deftypefun size_t strxfrm (char *restrict @var{to}, const char *restrict @var{from}, size_t @var{size})
1513 @standards{ISO, string.h}
1514 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1515 The function @code{strxfrm} transforms the multibyte string
1516 @var{from} using the
1517 collation transformation determined by the locale currently selected for
1518 collation, and stores the transformed string in the array @var{to}.  Up
1519 to @var{size} bytes (including a terminating null byte) are
1520 stored.
1522 The behavior is undefined if the strings @var{to} and @var{from}
1523 overlap; see @ref{Copying Strings and Arrays}.
1525 The return value is the length of the entire transformed string.  This
1526 value is not affected by the value of @var{size}, but if it is greater
1527 or equal than @var{size}, it means that the transformed string did not
1528 entirely fit in the array @var{to}.  In this case, only as much of the
1529 string as actually fits was stored.  To get the whole transformed
1530 string, call @code{strxfrm} again with a bigger output array.
1532 The transformed string may be longer than the original string, and it
1533 may also be shorter.
1535 If @var{size} is zero, no bytes are stored in @var{to}.  In this
1536 case, @code{strxfrm} simply returns the number of bytes that would
1537 be the length of the transformed string.  This is useful for determining
1538 what size the allocated array should be.  It does not matter what
1539 @var{to} is if @var{size} is zero; @var{to} may even be a null pointer.
1540 @end deftypefun
1542 @deftypefun size_t wcsxfrm (wchar_t *restrict @var{wto}, const wchar_t *@var{wfrom}, size_t @var{size})
1543 @standards{ISO, wchar.h}
1544 @safety{@prelim{}@mtsafe{@mtslocale{}}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
1545 The function @code{wcsxfrm} transforms wide string @var{wfrom}
1546 using the collation transformation determined by the locale currently
1547 selected for collation, and stores the transformed string in the array
1548 @var{wto}.  Up to @var{size} wide characters (including a terminating null
1549 wide character) are stored.
1551 The behavior is undefined if the strings @var{wto} and @var{wfrom}
1552 overlap; see @ref{Copying Strings and Arrays}.
1554 The return value is the length of the entire transformed wide
1555 string.  This value is not affected by the value of @var{size}, but if
1556 it is greater or equal than @var{size}, it means that the transformed
1557 wide string did not entirely fit in the array @var{wto}.  In
1558 this case, only as much of the wide string as actually fits
1559 was stored.  To get the whole transformed wide string, call
1560 @code{wcsxfrm} again with a bigger output array.
1562 The transformed wide string may be longer than the original
1563 wide string, and it may also be shorter.
1565 If @var{size} is zero, no wide characters are stored in @var{to}.  In this
1566 case, @code{wcsxfrm} simply returns the number of wide characters that
1567 would be the length of the transformed wide string.  This is
1568 useful for determining what size the allocated array should be (remember
1569 to multiply with @code{sizeof (wchar_t)}).  It does not matter what
1570 @var{wto} is if @var{size} is zero; @var{wto} may even be a null pointer.
1571 @end deftypefun
1573 Here is an example of how you can use @code{strxfrm} when
1574 you plan to do many comparisons.  It does the same thing as the previous
1575 example, but much faster, because it has to transform each string only
1576 once, no matter how many times it is compared with other strings.  Even
1577 the time needed to allocate and free storage is much less than the time
1578 we save, when there are many strings.
1580 @smallexample
1581 struct sorter @{ char *input; char *transformed; @};
1583 /* @r{This is the comparison function used with @code{qsort}}
1584    @r{to sort an array of @code{struct sorter}.} */
1587 compare_elements (const void *v1, const void *v2)
1589   const struct sorter *p1 = v1;
1590   const struct sorter *p2 = v2;
1592   return strcmp (p1->transformed, p2->transformed);
1595 /* @r{This is the entry point---the function to sort}
1596    @r{strings using the locale's collating sequence.} */
1598 void
1599 sort_strings_fast (char **array, int nstrings)
1601   struct sorter temp_array[nstrings];
1602   int i;
1604   /* @r{Set up @code{temp_array}.  Each element contains}
1605      @r{one input string and its transformed string.} */
1606   for (i = 0; i < nstrings; i++)
1607     @{
1608       size_t length = strlen (array[i]) * 2;
1609       char *transformed;
1610       size_t transformed_length;
1612       temp_array[i].input = array[i];
1614       /* @r{First try a buffer perhaps big enough.}  */
1615       transformed = (char *) xmalloc (length);
1617       /* @r{Transform @code{array[i]}.}  */
1618       transformed_length = strxfrm (transformed, array[i], length);
1620       /* @r{If the buffer was not large enough, resize it}
1621          @r{and try again.}  */
1622       if (transformed_length >= length)
1623         @{
1624           /* @r{Allocate the needed space. +1 for terminating}
1625              @r{@code{'\0'} byte.}  */
1626           transformed = xrealloc (transformed,
1627                                   transformed_length + 1);
1629           /* @r{The return value is not interesting because we know}
1630              @r{how long the transformed string is.}  */
1631           (void) strxfrm (transformed, array[i],
1632                           transformed_length + 1);
1633         @}
1635       temp_array[i].transformed = transformed;
1636     @}
1638   /* @r{Sort @code{temp_array} by comparing transformed strings.} */
1639   qsort (temp_array, nstrings,
1640          sizeof (struct sorter), compare_elements);
1642   /* @r{Put the elements back in the permanent array}
1643      @r{in their sorted order.} */
1644   for (i = 0; i < nstrings; i++)
1645     array[i] = temp_array[i].input;
1647   /* @r{Free the strings we allocated.} */
1648   for (i = 0; i < nstrings; i++)
1649     free (temp_array[i].transformed);
1651 @end smallexample
1653 The interesting part of this code for the wide character version would
1654 look like this:
1656 @smallexample
1657 void
1658 sort_strings_fast (wchar_t **array, int nstrings)
1660   @dots{}
1661       /* @r{Transform @code{array[i]}.}  */
1662       transformed_length = wcsxfrm (transformed, array[i], length);
1664       /* @r{If the buffer was not large enough, resize it}
1665          @r{and try again.}  */
1666       if (transformed_length >= length)
1667         @{
1668           /* @r{Allocate the needed space. +1 for terminating}
1669              @r{@code{L'\0'} wide character.}  */
1670           transformed = xreallocarray (transformed,
1671                                        transformed_length + 1,
1672                                        sizeof *transformed);
1674           /* @r{The return value is not interesting because we know}
1675              @r{how long the transformed string is.}  */
1676           (void) wcsxfrm (transformed, array[i],
1677                           transformed_length + 1);
1678         @}
1679   @dots{}
1680 @end smallexample
1682 @noindent
1683 Note the additional multiplication with @code{sizeof (wchar_t)} in the
1684 @code{realloc} call.
1686 @strong{Compatibility Note:} The string collation functions are a new
1687 feature of @w{ISO C90}.  Older C dialects have no equivalent feature.
1688 The wide character versions were introduced in @w{Amendment 1} to @w{ISO
1689 C90}.
1691 @node Search Functions
1692 @section Search Functions
1694 This section describes library functions which perform various kinds
1695 of searching operations on strings and arrays.  These functions are
1696 declared in the header file @file{string.h}.
1697 @pindex string.h
1698 @cindex search functions (for strings)
1699 @cindex string search functions
1701 @deftypefun {void *} memchr (const void *@var{block}, int @var{c}, size_t @var{size})
1702 @standards{ISO, string.h}
1703 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1704 This function finds the first occurrence of the byte @var{c} (converted
1705 to an @code{unsigned char}) in the initial @var{size} bytes of the
1706 object beginning at @var{block}.  The return value is a pointer to the
1707 located byte, or a null pointer if no match was found.
1708 @end deftypefun
1710 @deftypefun {wchar_t *} wmemchr (const wchar_t *@var{block}, wchar_t @var{wc}, size_t @var{size})
1711 @standards{ISO, wchar.h}
1712 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1713 This function finds the first occurrence of the wide character @var{wc}
1714 in the initial @var{size} wide characters of the object beginning at
1715 @var{block}.  The return value is a pointer to the located wide
1716 character, or a null pointer if no match was found.
1717 @end deftypefun
1719 @deftypefun {void *} rawmemchr (const void *@var{block}, int @var{c})
1720 @standards{GNU, string.h}
1721 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1722 Often the @code{memchr} function is used with the knowledge that the
1723 byte @var{c} is available in the memory block specified by the
1724 parameters.  But this means that the @var{size} parameter is not really
1725 needed and that the tests performed with it at runtime (to check whether
1726 the end of the block is reached) are not needed.
1728 The @code{rawmemchr} function exists for just this situation which is
1729 surprisingly frequent.  The interface is similar to @code{memchr} except
1730 that the @var{size} parameter is missing.  The function will look beyond
1731 the end of the block pointed to by @var{block} in case the programmer
1732 made an error in assuming that the byte @var{c} is present in the block.
1733 In this case the result is unspecified.  Otherwise the return value is a
1734 pointer to the located byte.
1736 When looking for the end of a string, use @code{strchr}.
1738 This function is a GNU extension.
1739 @end deftypefun
1741 @deftypefun {void *} memrchr (const void *@var{block}, int @var{c}, size_t @var{size})
1742 @standards{GNU, string.h}
1743 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1744 The function @code{memrchr} is like @code{memchr}, except that it searches
1745 backwards from the end of the block defined by @var{block} and @var{size}
1746 (instead of forwards from the front).
1748 This function is a GNU extension.
1749 @end deftypefun
1751 @deftypefun {char *} strchr (const char *@var{string}, int @var{c})
1752 @standards{ISO, string.h}
1753 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1754 The @code{strchr} function finds the first occurrence of the byte
1755 @var{c} (converted to a @code{char}) in the string
1756 beginning at @var{string}.  The return value is a pointer to the located
1757 byte, or a null pointer if no match was found.
1759 For example,
1760 @smallexample
1761 strchr ("hello, world", 'l')
1762     @result{} "llo, world"
1763 strchr ("hello, world", '?')
1764     @result{} NULL
1765 @end smallexample
1767 The terminating null byte is considered to be part of the string,
1768 so you can use this function get a pointer to the end of a string by
1769 specifying zero as the value of the @var{c} argument.
1771 When @code{strchr} returns a null pointer, it does not let you know
1772 the position of the terminating null byte it has found.  If you
1773 need that information, it is better (but less portable) to use
1774 @code{strchrnul} than to search for it a second time.
1775 @end deftypefun
1777 @deftypefun {wchar_t *} wcschr (const wchar_t *@var{wstring}, wchar_t @var{wc})
1778 @standards{ISO, wchar.h}
1779 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1780 The @code{wcschr} function finds the first occurrence of the wide
1781 character @var{wc} in the wide string
1782 beginning at @var{wstring}.  The return value is a pointer to the
1783 located wide character, or a null pointer if no match was found.
1785 The terminating null wide character is considered to be part of the wide
1786 string, so you can use this function get a pointer to the end
1787 of a wide string by specifying a null wide character as the
1788 value of the @var{wc} argument.  It would be better (but less portable)
1789 to use @code{wcschrnul} in this case, though.
1790 @end deftypefun
1792 @deftypefun {char *} strchrnul (const char *@var{string}, int @var{c})
1793 @standards{GNU, string.h}
1794 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1795 @code{strchrnul} is the same as @code{strchr} except that if it does
1796 not find the byte, it returns a pointer to string's terminating
1797 null byte rather than a null pointer.
1799 This function is a GNU extension.
1800 @end deftypefun
1802 @deftypefun {wchar_t *} wcschrnul (const wchar_t *@var{wstring}, wchar_t @var{wc})
1803 @standards{GNU, wchar.h}
1804 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1805 @code{wcschrnul} is the same as @code{wcschr} except that if it does not
1806 find the wide character, it returns a pointer to the wide string's
1807 terminating null wide character rather than a null pointer.
1809 This function is a GNU extension.
1810 @end deftypefun
1812 One useful, but unusual, use of the @code{strchr}
1813 function is when one wants to have a pointer pointing to the null byte
1814 terminating a string.  This is often written in this way:
1816 @smallexample
1817   s += strlen (s);
1818 @end smallexample
1820 @noindent
1821 This is almost optimal but the addition operation duplicated a bit of
1822 the work already done in the @code{strlen} function.  A better solution
1823 is this:
1825 @smallexample
1826   s = strchr (s, '\0');
1827 @end smallexample
1829 There is no restriction on the second parameter of @code{strchr} so it
1830 could very well also be zero.  Those readers thinking very
1831 hard about this might now point out that the @code{strchr} function is
1832 more expensive than the @code{strlen} function since we have two abort
1833 criteria.  This is right.  But in @theglibc{} the implementation of
1834 @code{strchr} is optimized in a special way so that @code{strchr}
1835 actually is faster.
1837 @deftypefun {char *} strrchr (const char *@var{string}, int @var{c})
1838 @standards{ISO, string.h}
1839 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1840 The function @code{strrchr} is like @code{strchr}, except that it searches
1841 backwards from the end of the string @var{string} (instead of forwards
1842 from the front).
1844 For example,
1845 @smallexample
1846 strrchr ("hello, world", 'l')
1847     @result{} "ld"
1848 @end smallexample
1849 @end deftypefun
1851 @deftypefun {wchar_t *} wcsrchr (const wchar_t *@var{wstring}, wchar_t @var{wc})
1852 @standards{ISO, wchar.h}
1853 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1854 The function @code{wcsrchr} is like @code{wcschr}, except that it searches
1855 backwards from the end of the string @var{wstring} (instead of forwards
1856 from the front).
1857 @end deftypefun
1859 @deftypefun {char *} strstr (const char *@var{haystack}, const char *@var{needle})
1860 @standards{ISO, string.h}
1861 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1862 This is like @code{strchr}, except that it searches @var{haystack} for a
1863 substring @var{needle} rather than just a single byte.  It
1864 returns a pointer into the string @var{haystack} that is the first
1865 byte of the substring, or a null pointer if no match was found.  If
1866 @var{needle} is an empty string, the function returns @var{haystack}.
1868 For example,
1869 @smallexample
1870 strstr ("hello, world", "l")
1871     @result{} "llo, world"
1872 strstr ("hello, world", "wo")
1873     @result{} "world"
1874 @end smallexample
1875 @end deftypefun
1877 @deftypefun {wchar_t *} wcsstr (const wchar_t *@var{haystack}, const wchar_t *@var{needle})
1878 @standards{ISO, wchar.h}
1879 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1880 This is like @code{wcschr}, except that it searches @var{haystack} for a
1881 substring @var{needle} rather than just a single wide character.  It
1882 returns a pointer into the string @var{haystack} that is the first wide
1883 character of the substring, or a null pointer if no match was found.  If
1884 @var{needle} is an empty string, the function returns @var{haystack}.
1885 @end deftypefun
1887 @deftypefun {wchar_t *} wcswcs (const wchar_t *@var{haystack}, const wchar_t *@var{needle})
1888 @standards{XPG, wchar.h}
1889 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1890 @code{wcswcs} is a deprecated alias for @code{wcsstr}.  This is the
1891 name originally used in the X/Open Portability Guide before the
1892 @w{Amendment 1} to @w{ISO C90} was published.
1893 @end deftypefun
1896 @deftypefun {char *} strcasestr (const char *@var{haystack}, const char *@var{needle})
1897 @standards{GNU, string.h}
1898 @safety{@prelim{}@mtsafe{@mtslocale{}}@assafe{}@acsafe{}}
1899 @c There may be multiple calls of strncasecmp, each accessing the locale
1900 @c object independently.
1901 This is like @code{strstr}, except that it ignores case in searching for
1902 the substring.   Like @code{strcasecmp}, it is locale dependent how
1903 uppercase and lowercase characters are related, and arguments are
1904 multibyte strings.
1907 For example,
1908 @smallexample
1909 strcasestr ("hello, world", "L")
1910     @result{} "llo, world"
1911 strcasestr ("hello, World", "wo")
1912     @result{} "World"
1913 @end smallexample
1914 @end deftypefun
1917 @deftypefun {void *} memmem (const void *@var{haystack}, size_t @var{haystack-len},@*const void *@var{needle}, size_t @var{needle-len})
1918 @standards{GNU, string.h}
1919 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1920 This is like @code{strstr}, but @var{needle} and @var{haystack} are byte
1921 arrays rather than strings.  @var{needle-len} is the
1922 length of @var{needle} and @var{haystack-len} is the length of
1923 @var{haystack}.
1925 This function is a GNU extension.
1926 @end deftypefun
1928 @deftypefun size_t strspn (const char *@var{string}, const char *@var{skipset})
1929 @standards{ISO, string.h}
1930 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1931 The @code{strspn} (``string span'') function returns the length of the
1932 initial substring of @var{string} that consists entirely of bytes that
1933 are members of the set specified by the string @var{skipset}.  The order
1934 of the bytes in @var{skipset} is not important.
1936 For example,
1937 @smallexample
1938 strspn ("hello, world", "abcdefghijklmnopqrstuvwxyz")
1939     @result{} 5
1940 @end smallexample
1942 In a multibyte string, characters consisting of
1943 more than one byte are not treated as single entities.  Each byte is treated
1944 separately.  The function is not locale-dependent.
1945 @end deftypefun
1947 @deftypefun size_t wcsspn (const wchar_t *@var{wstring}, const wchar_t *@var{skipset})
1948 @standards{ISO, wchar.h}
1949 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1950 The @code{wcsspn} (``wide character string span'') function returns the
1951 length of the initial substring of @var{wstring} that consists entirely
1952 of wide characters that are members of the set specified by the string
1953 @var{skipset}.  The order of the wide characters in @var{skipset} is not
1954 important.
1955 @end deftypefun
1957 @deftypefun size_t strcspn (const char *@var{string}, const char *@var{stopset})
1958 @standards{ISO, string.h}
1959 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1960 The @code{strcspn} (``string complement span'') function returns the length
1961 of the initial substring of @var{string} that consists entirely of bytes
1962 that are @emph{not} members of the set specified by the string @var{stopset}.
1963 (In other words, it returns the offset of the first byte in @var{string}
1964 that is a member of the set @var{stopset}.)
1966 For example,
1967 @smallexample
1968 strcspn ("hello, world", " \t\n,.;!?")
1969     @result{} 5
1970 @end smallexample
1972 In a multibyte string, characters consisting of
1973 more than one byte are not treated as a single entities.  Each byte is treated
1974 separately.  The function is not locale-dependent.
1975 @end deftypefun
1977 @deftypefun size_t wcscspn (const wchar_t *@var{wstring}, const wchar_t *@var{stopset})
1978 @standards{ISO, wchar.h}
1979 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1980 The @code{wcscspn} (``wide character string complement span'') function
1981 returns the length of the initial substring of @var{wstring} that
1982 consists entirely of wide characters that are @emph{not} members of the
1983 set specified by the string @var{stopset}.  (In other words, it returns
1984 the offset of the first wide character in @var{string} that is a member of
1985 the set @var{stopset}.)
1986 @end deftypefun
1988 @deftypefun {char *} strpbrk (const char *@var{string}, const char *@var{stopset})
1989 @standards{ISO, string.h}
1990 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1991 The @code{strpbrk} (``string pointer break'') function is related to
1992 @code{strcspn}, except that it returns a pointer to the first byte
1993 in @var{string} that is a member of the set @var{stopset} instead of the
1994 length of the initial substring.  It returns a null pointer if no such
1995 byte from @var{stopset} is found.
1997 @c @group  Invalid outside the example.
1998 For example,
2000 @smallexample
2001 strpbrk ("hello, world", " \t\n,.;!?")
2002     @result{} ", world"
2003 @end smallexample
2004 @c @end group
2006 In a multibyte string, characters consisting of
2007 more than one byte are not treated as single entities.  Each byte is treated
2008 separately.  The function is not locale-dependent.
2009 @end deftypefun
2011 @deftypefun {wchar_t *} wcspbrk (const wchar_t *@var{wstring}, const wchar_t *@var{stopset})
2012 @standards{ISO, wchar.h}
2013 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2014 The @code{wcspbrk} (``wide character string pointer break'') function is
2015 related to @code{wcscspn}, except that it returns a pointer to the first
2016 wide character in @var{wstring} that is a member of the set
2017 @var{stopset} instead of the length of the initial substring.  It
2018 returns a null pointer if no such wide character from @var{stopset} is found.
2019 @end deftypefun
2022 @subsection Compatibility String Search Functions
2024 @deftypefun {char *} index (const char *@var{string}, int @var{c})
2025 @standards{BSD, string.h}
2026 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2027 @code{index} is another name for @code{strchr}; they are exactly the same.
2028 New code should always use @code{strchr} since this name is defined in
2029 @w{ISO C} while @code{index} is a BSD invention which never was available
2030 on @w{System V} derived systems.
2031 @end deftypefun
2033 @deftypefun {char *} rindex (const char *@var{string}, int @var{c})
2034 @standards{BSD, string.h}
2035 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2036 @code{rindex} is another name for @code{strrchr}; they are exactly the same.
2037 New code should always use @code{strrchr} since this name is defined in
2038 @w{ISO C} while @code{rindex} is a BSD invention which never was available
2039 on @w{System V} derived systems.
2040 @end deftypefun
2042 @node Finding Tokens in a String
2043 @section Finding Tokens in a String
2045 @cindex tokenizing strings
2046 @cindex breaking a string into tokens
2047 @cindex parsing tokens from a string
2048 It's fairly common for programs to have a need to do some simple kinds
2049 of lexical analysis and parsing, such as splitting a command string up
2050 into tokens.  You can do this with the @code{strtok} function, declared
2051 in the header file @file{string.h}.
2052 @pindex string.h
2054 @deftypefun {char *} strtok (char *restrict @var{newstring}, const char *restrict @var{delimiters})
2055 @standards{ISO, string.h}
2056 @safety{@prelim{}@mtunsafe{@mtasurace{:strtok}}@asunsafe{}@acsafe{}}
2057 A string can be split into tokens by making a series of calls to the
2058 function @code{strtok}.
2060 The string to be split up is passed as the @var{newstring} argument on
2061 the first call only.  The @code{strtok} function uses this to set up
2062 some internal state information.  Subsequent calls to get additional
2063 tokens from the same string are indicated by passing a null pointer as
2064 the @var{newstring} argument.  Calling @code{strtok} with another
2065 non-null @var{newstring} argument reinitializes the state information.
2066 It is guaranteed that no other library function ever calls @code{strtok}
2067 behind your back (which would mess up this internal state information).
2069 The @var{delimiters} argument is a string that specifies a set of delimiters
2070 that may surround the token being extracted.  All the initial bytes
2071 that are members of this set are discarded.  The first byte that is
2072 @emph{not} a member of this set of delimiters marks the beginning of the
2073 next token.  The end of the token is found by looking for the next
2074 byte that is a member of the delimiter set.  This byte in the
2075 original string @var{newstring} is overwritten by a null byte, and the
2076 pointer to the beginning of the token in @var{newstring} is returned.
2078 On the next call to @code{strtok}, the searching begins at the next
2079 byte beyond the one that marked the end of the previous token.
2080 Note that the set of delimiters @var{delimiters} do not have to be the
2081 same on every call in a series of calls to @code{strtok}.
2083 If the end of the string @var{newstring} is reached, or if the remainder of
2084 string consists only of delimiter bytes, @code{strtok} returns
2085 a null pointer.
2087 In a multibyte string, characters consisting of
2088 more than one byte are not treated as single entities.  Each byte is treated
2089 separately.  The function is not locale-dependent.
2090 @end deftypefun
2092 @deftypefun {wchar_t *} wcstok (wchar_t *@var{newstring}, const wchar_t *@var{delimiters}, wchar_t **@var{save_ptr})
2093 @standards{ISO, wchar.h}
2094 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2095 A string can be split into tokens by making a series of calls to the
2096 function @code{wcstok}.
2098 The string to be split up is passed as the @var{newstring} argument on
2099 the first call only.  The @code{wcstok} function uses this to set up
2100 some internal state information.  Subsequent calls to get additional
2101 tokens from the same wide string are indicated by passing a
2102 null pointer as the @var{newstring} argument, which causes the pointer
2103 previously stored in @var{save_ptr} to be used instead.
2105 The @var{delimiters} argument is a wide string that specifies
2106 a set of delimiters that may surround the token being extracted.  All
2107 the initial wide characters that are members of this set are discarded.
2108 The first wide character that is @emph{not} a member of this set of
2109 delimiters marks the beginning of the next token.  The end of the token
2110 is found by looking for the next wide character that is a member of the
2111 delimiter set.  This wide character in the original wide
2112 string @var{newstring} is overwritten by a null wide character, the
2113 pointer past the overwritten wide character is saved in @var{save_ptr},
2114 and the pointer to the beginning of the token in @var{newstring} is
2115 returned.
2117 On the next call to @code{wcstok}, the searching begins at the next
2118 wide character beyond the one that marked the end of the previous token.
2119 Note that the set of delimiters @var{delimiters} do not have to be the
2120 same on every call in a series of calls to @code{wcstok}.
2122 If the end of the wide string @var{newstring} is reached, or
2123 if the remainder of string consists only of delimiter wide characters,
2124 @code{wcstok} returns a null pointer.
2125 @end deftypefun
2127 @strong{Warning:} Since @code{strtok} and @code{wcstok} alter the string
2128 they is parsing, you should always copy the string to a temporary buffer
2129 before parsing it with @code{strtok}/@code{wcstok} (@pxref{Copying Strings
2130 and Arrays}).  If you allow @code{strtok} or @code{wcstok} to modify
2131 a string that came from another part of your program, you are asking for
2132 trouble; that string might be used for other purposes after
2133 @code{strtok} or @code{wcstok} has modified it, and it would not have
2134 the expected value.
2136 The string that you are operating on might even be a constant.  Then
2137 when @code{strtok} or @code{wcstok} tries to modify it, your program
2138 will get a fatal signal for writing in read-only memory.  @xref{Program
2139 Error Signals}.  Even if the operation of @code{strtok} or @code{wcstok}
2140 would not require a modification of the string (e.g., if there is
2141 exactly one token) the string can (and in the @glibcadj{} case will) be
2142 modified.
2144 This is a special case of a general principle: if a part of a program
2145 does not have as its purpose the modification of a certain data
2146 structure, then it is error-prone to modify the data structure
2147 temporarily.
2149 The function @code{strtok} is not reentrant, whereas @code{wcstok} is.
2150 @xref{Nonreentrancy}, for a discussion of where and why reentrancy is
2151 important.
2153 Here is a simple example showing the use of @code{strtok}.
2155 @comment Yes, this example has been tested.
2156 @smallexample
2157 #include <string.h>
2158 #include <stddef.h>
2160 @dots{}
2162 const char string[] = "words separated by spaces -- and, punctuation!";
2163 const char delimiters[] = " .,;:!-";
2164 char *token, *cp;
2166 @dots{}
2168 cp = strdupa (string);                /* Make writable copy.  */
2169 token = strtok (cp, delimiters);      /* token => "words" */
2170 token = strtok (NULL, delimiters);    /* token => "separated" */
2171 token = strtok (NULL, delimiters);    /* token => "by" */
2172 token = strtok (NULL, delimiters);    /* token => "spaces" */
2173 token = strtok (NULL, delimiters);    /* token => "and" */
2174 token = strtok (NULL, delimiters);    /* token => "punctuation" */
2175 token = strtok (NULL, delimiters);    /* token => NULL */
2176 @end smallexample
2178 @Theglibc{} contains two more functions for tokenizing a string
2179 which overcome the limitation of non-reentrancy.  They are not
2180 available available for wide strings.
2182 @deftypefun {char *} strtok_r (char *@var{newstring}, const char *@var{delimiters}, char **@var{save_ptr})
2183 @standards{POSIX, string.h}
2184 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2185 Just like @code{strtok}, this function splits the string into several
2186 tokens which can be accessed by successive calls to @code{strtok_r}.
2187 The difference is that, as in @code{wcstok}, the information about the
2188 next token is stored in the space pointed to by the third argument,
2189 @var{save_ptr}, which is a pointer to a string pointer.  Calling
2190 @code{strtok_r} with a null pointer for @var{newstring} and leaving
2191 @var{save_ptr} between the calls unchanged does the job without
2192 hindering reentrancy.
2194 This function is defined in POSIX.1 and can be found on many systems
2195 which support multi-threading.
2196 @end deftypefun
2198 @deftypefun {char *} strsep (char **@var{string_ptr}, const char *@var{delimiter})
2199 @standards{BSD, string.h}
2200 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2201 This function has a similar functionality as @code{strtok_r} with the
2202 @var{newstring} argument replaced by the @var{save_ptr} argument.  The
2203 initialization of the moving pointer has to be done by the user.
2204 Successive calls to @code{strsep} move the pointer along the tokens
2205 separated by @var{delimiter}, returning the address of the next token
2206 and updating @var{string_ptr} to point to the beginning of the next
2207 token.
2209 One difference between @code{strsep} and @code{strtok_r} is that if the
2210 input string contains more than one byte from @var{delimiter} in a
2211 row @code{strsep} returns an empty string for each pair of bytes
2212 from @var{delimiter}.  This means that a program normally should test
2213 for @code{strsep} returning an empty string before processing it.
2215 This function was introduced in 4.3BSD and therefore is widely available.
2216 @end deftypefun
2218 Here is how the above example looks like when @code{strsep} is used.
2220 @comment Yes, this example has been tested.
2221 @smallexample
2222 #include <string.h>
2223 #include <stddef.h>
2225 @dots{}
2227 const char string[] = "words separated by spaces -- and, punctuation!";
2228 const char delimiters[] = " .,;:!-";
2229 char *running;
2230 char *token;
2232 @dots{}
2234 running = strdupa (string);
2235 token = strsep (&running, delimiters);    /* token => "words" */
2236 token = strsep (&running, delimiters);    /* token => "separated" */
2237 token = strsep (&running, delimiters);    /* token => "by" */
2238 token = strsep (&running, delimiters);    /* token => "spaces" */
2239 token = strsep (&running, delimiters);    /* token => "" */
2240 token = strsep (&running, delimiters);    /* token => "" */
2241 token = strsep (&running, delimiters);    /* token => "" */
2242 token = strsep (&running, delimiters);    /* token => "and" */
2243 token = strsep (&running, delimiters);    /* token => "" */
2244 token = strsep (&running, delimiters);    /* token => "punctuation" */
2245 token = strsep (&running, delimiters);    /* token => "" */
2246 token = strsep (&running, delimiters);    /* token => NULL */
2247 @end smallexample
2249 @deftypefun {char *} basename (const char *@var{filename})
2250 @standards{GNU, string.h}
2251 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2252 The GNU version of the @code{basename} function returns the last
2253 component of the path in @var{filename}.  This function is the preferred
2254 usage, since it does not modify the argument, @var{filename}, and
2255 respects trailing slashes.  The prototype for @code{basename} can be
2256 found in @file{string.h}.  Note, this function is overridden by the XPG
2257 version, if @file{libgen.h} is included.
2259 Example of using GNU @code{basename}:
2261 @smallexample
2262 #include <string.h>
2265 main (int argc, char *argv[])
2267   char *prog = basename (argv[0]);
2269   if (argc < 2)
2270     @{
2271       fprintf (stderr, "Usage %s <arg>\n", prog);
2272       exit (1);
2273     @}
2275   @dots{}
2277 @end smallexample
2279 @strong{Portability Note:} This function may produce different results
2280 on different systems.
2282 @end deftypefun
2284 @deftypefun {char *} basename (char *@var{path})
2285 @standards{XPG, libgen.h}
2286 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2287 This is the standard XPG defined @code{basename}.  It is similar in
2288 spirit to the GNU version, but may modify the @var{path} by removing
2289 trailing '/' bytes.  If the @var{path} is made up entirely of '/'
2290 bytes, then "/" will be returned.  Also, if @var{path} is
2291 @code{NULL} or an empty string, then "." is returned.  The prototype for
2292 the XPG version can be found in @file{libgen.h}.
2294 Example of using XPG @code{basename}:
2296 @smallexample
2297 #include <libgen.h>
2300 main (int argc, char *argv[])
2302   char *prog;
2303   char *path = strdupa (argv[0]);
2305   prog = basename (path);
2307   if (argc < 2)
2308     @{
2309       fprintf (stderr, "Usage %s <arg>\n", prog);
2310       exit (1);
2311     @}
2313   @dots{}
2316 @end smallexample
2317 @end deftypefun
2319 @deftypefun {char *} dirname (char *@var{path})
2320 @standards{XPG, libgen.h}
2321 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2322 The @code{dirname} function is the compliment to the XPG version of
2323 @code{basename}.  It returns the parent directory of the file specified
2324 by @var{path}.  If @var{path} is @code{NULL}, an empty string, or
2325 contains no '/' bytes, then "." is returned.  The prototype for this
2326 function can be found in @file{libgen.h}.
2327 @end deftypefun
2329 @node Erasing Sensitive Data
2330 @section Erasing Sensitive Data
2332 Sensitive data, such as cryptographic keys, should be erased from
2333 memory after use, to reduce the risk that a bug will expose it to the
2334 outside world.  However, compiler optimizations may determine that an
2335 erasure operation is ``unnecessary,'' and remove it from the generated
2336 code, because no @emph{correct} program could access the variable or
2337 heap object containing the sensitive data after it's deallocated.
2338 Since erasure is a precaution against bugs, this optimization is
2339 inappropriate.
2341 The function @code{explicit_bzero} erases a block of memory, and
2342 guarantees that the compiler will not remove the erasure as
2343 ``unnecessary.''
2345 @smallexample
2346 @group
2347 #include <string.h>
2349 extern void encrypt (const char *key, const char *in,
2350                      char *out, size_t n);
2351 extern void genkey (const char *phrase, char *key);
2353 void encrypt_with_phrase (const char *phrase, const char *in,
2354                           char *out, size_t n)
2356   char key[16];
2357   genkey (phrase, key);
2358   encrypt (key, in, out, n);
2359   explicit_bzero (key, 16);
2361 @end group
2362 @end smallexample
2364 @noindent
2365 In this example, if @code{memset}, @code{bzero}, or a hand-written
2366 loop had been used, the compiler might remove them as ``unnecessary.''
2368 @strong{Warning:} @code{explicit_bzero} does not guarantee that
2369 sensitive data is @emph{completely} erased from the computer's memory.
2370 There may be copies in temporary storage areas, such as registers and
2371 ``scratch'' stack space; since these are invisible to the source code,
2372 a library function cannot erase them.
2374 Also, @code{explicit_bzero} only operates on RAM.  If a sensitive data
2375 object never needs to have its address taken other than to call
2376 @code{explicit_bzero}, it might be stored entirely in CPU registers
2377 @emph{until} the call to @code{explicit_bzero}.  Then it will be
2378 copied into RAM, the copy will be erased, and the original will remain
2379 intact.  Data in RAM is more likely to be exposed by a bug than data
2380 in registers, so this creates a brief window where the data is at
2381 greater risk of exposure than it would have been if the program didn't
2382 try to erase it at all.
2384 Declaring sensitive variables as @code{volatile} will make both the
2385 above problems @emph{worse}; a @code{volatile} variable will be stored
2386 in memory for its entire lifetime, and the compiler will make
2387 @emph{more} copies of it than it would otherwise have.  Attempting to
2388 erase a normal variable ``by hand'' through a
2389 @code{volatile}-qualified pointer doesn't work at all---because the
2390 variable itself is not @code{volatile}, some compilers will ignore the
2391 qualification on the pointer and remove the erasure anyway.
2393 Having said all that, in most situations, using @code{explicit_bzero}
2394 is better than not using it.  At present, the only way to do a more
2395 thorough job is to write the entire sensitive operation in assembly
2396 language.  We anticipate that future compilers will recognize calls to
2397 @code{explicit_bzero} and take appropriate steps to erase all the
2398 copies of the affected data, wherever they may be.
2400 @deftypefun void explicit_bzero (void *@var{block}, size_t @var{len})
2401 @standards{BSD, string.h}
2402 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2404 @code{explicit_bzero} writes zero into @var{len} bytes of memory
2405 beginning at @var{block}, just as @code{bzero} would.  The zeroes are
2406 always written, even if the compiler could determine that this is
2407 ``unnecessary'' because no correct program could read them back.
2409 @strong{Note:} The @emph{only} optimization that @code{explicit_bzero}
2410 disables is removal of ``unnecessary'' writes to memory.  The compiler
2411 can perform all the other optimizations that it could for a call to
2412 @code{memset}.  For instance, it may replace the function call with
2413 inline memory writes, and it may assume that @var{block} cannot be a
2414 null pointer.
2416 @strong{Portability Note:} This function first appeared in OpenBSD 5.5
2417 and has not been standardized.  Other systems may provide the same
2418 functionality under a different name, such as @code{explicit_memset},
2419 @code{memset_s}, or @code{SecureZeroMemory}.
2421 @Theglibc{} declares this function in @file{string.h}, but on other
2422 systems it may be in @file{strings.h} instead.
2423 @end deftypefun
2426 @node Shuffling Bytes
2427 @section Shuffling Bytes
2429 The function below addresses the perennial programming quandary: ``How do
2430 I take good data in string form and painlessly turn it into garbage?''
2431 This is not a difficult thing to code for oneself, but the authors of
2432 @theglibc{} wish to make it as convenient as possible.
2434 To @emph{erase} data, use @code{explicit_bzero} (@pxref{Erasing
2435 Sensitive Data}); to obfuscate it reversibly, use @code{memfrob}
2436 (@pxref{Obfuscating Data}).
2438 @deftypefun {char *} strfry (char *@var{string})
2439 @standards{GNU, string.h}
2440 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2441 @c Calls initstate_r, time, getpid, strlen, and random_r.
2443 @code{strfry} performs an in-place shuffle on @var{string}.  Each
2444 character is swapped to a position selected at random, within the
2445 portion of the string starting with the character's original position.
2446 (This is the Fisher-Yates algorithm for unbiased shuffling.)
2448 Calling @code{strfry} will not disturb any of the random number
2449 generators that have global state (@pxref{Pseudo-Random Numbers}).
2451 The return value of @code{strfry} is always @var{string}.
2453 @strong{Portability Note:}  This function is unique to @theglibc{}.
2454 It is declared in @file{string.h}.
2455 @end deftypefun
2458 @node Obfuscating Data
2459 @section Obfuscating Data
2460 @cindex Rot13
2462 The @code{memfrob} function reversibly obfuscates an array of binary
2463 data.  This is not true encryption; the obfuscated data still bears a
2464 clear relationship to the original, and no secret key is required to
2465 undo the obfuscation.  It is analogous to the ``Rot13'' cipher used on
2466 Usenet for obscuring offensive jokes, spoilers for works of fiction,
2467 and so on, but it can be applied to arbitrary binary data.
2469 Programs that need true encryption---a transformation that completely
2470 obscures the original and cannot be reversed without knowledge of a
2471 secret key---should use a dedicated cryptography library, such as
2472 @uref{https://www.gnu.org/software/libgcrypt/,,libgcrypt}.
2474 Programs that need to @emph{destroy} data should use
2475 @code{explicit_bzero} (@pxref{Erasing Sensitive Data}), or possibly
2476 @code{strfry} (@pxref{Shuffling Bytes}).
2478 @deftypefun {void *} memfrob (void *@var{mem}, size_t @var{length})
2479 @standards{GNU, string.h}
2480 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2482 The function @code{memfrob} obfuscates @var{length} bytes of data
2483 beginning at @var{mem}, in place.  Each byte is bitwise xor-ed with
2484 the binary pattern 00101010 (hexadecimal 0x2A).  The return value is
2485 always @var{mem}.
2487 @code{memfrob} a second time on the same data returns it to
2488 its original state.
2490 @strong{Portability Note:}  This function is unique to @theglibc{}.
2491 It is declared in @file{string.h}.
2492 @end deftypefun
2494 @node Encode Binary Data
2495 @section Encode Binary Data
2497 To store or transfer binary data in environments which only support text
2498 one has to encode the binary data by mapping the input bytes to
2499 bytes in the range allowed for storing or transferring.  SVID
2500 systems (and nowadays XPG compliant systems) provide minimal support for
2501 this task.
2503 @deftypefun {char *} l64a (long int @var{n})
2504 @standards{XPG, stdlib.h}
2505 @safety{@prelim{}@mtunsafe{@mtasurace{:l64a}}@asunsafe{}@acsafe{}}
2506 This function encodes a 32-bit input value using bytes from the
2507 basic character set.  It returns a pointer to a 7 byte buffer which
2508 contains an encoded version of @var{n}.  To encode a series of bytes the
2509 user must copy the returned string to a destination buffer.  It returns
2510 the empty string if @var{n} is zero, which is somewhat bizarre but
2511 mandated by the standard.@*
2512 @strong{Warning:} Since a static buffer is used this function should not
2513 be used in multi-threaded programs.  There is no thread-safe alternative
2514 to this function in the C library.@*
2515 @strong{Compatibility Note:} The XPG standard states that the return
2516 value of @code{l64a} is undefined if @var{n} is negative.  In the GNU
2517 implementation, @code{l64a} treats its argument as unsigned, so it will
2518 return a sensible encoding for any nonzero @var{n}; however, portable
2519 programs should not rely on this.
2521 To encode a large buffer @code{l64a} must be called in a loop, once for
2522 each 32-bit word of the buffer.  For example, one could do something
2523 like this:
2525 @smallexample
2526 char *
2527 encode (const void *buf, size_t len)
2529   /* @r{We know in advance how long the buffer has to be.} */
2530   unsigned char *in = (unsigned char *) buf;
2531   char *out = malloc (6 + ((len + 3) / 4) * 6 + 1);
2532   char *cp = out, *p;
2534   /* @r{Encode the length.} */
2535   /* @r{Using `htonl' is necessary so that the data can be}
2536      @r{decoded even on machines with different byte order.}
2537      @r{`l64a' can return a string shorter than 6 bytes, so }
2538      @r{we pad it with encoding of 0 (}'.'@r{) at the end by }
2539      @r{hand.} */
2541   p = stpcpy (cp, l64a (htonl (len)));
2542   cp = mempcpy (p, "......", 6 - (p - cp));
2544   while (len > 3)
2545     @{
2546       unsigned long int n = *in++;
2547       n = (n << 8) | *in++;
2548       n = (n << 8) | *in++;
2549       n = (n << 8) | *in++;
2550       len -= 4;
2551       p = stpcpy (cp, l64a (htonl (n)));
2552       cp = mempcpy (p, "......", 6 - (p - cp));
2553     @}
2554   if (len > 0)
2555     @{
2556       unsigned long int n = *in++;
2557       if (--len > 0)
2558         @{
2559           n = (n << 8) | *in++;
2560           if (--len > 0)
2561             n = (n << 8) | *in;
2562         @}
2563       cp = stpcpy (cp, l64a (htonl (n)));
2564     @}
2565   *cp = '\0';
2566   return out;
2568 @end smallexample
2570 It is strange that the library does not provide the complete
2571 functionality needed but so be it.
2573 @end deftypefun
2575 To decode data produced with @code{l64a} the following function should be
2576 used.
2578 @deftypefun {long int} a64l (const char *@var{string})
2579 @standards{XPG, stdlib.h}
2580 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2581 The parameter @var{string} should contain a string which was produced by
2582 a call to @code{l64a}.  The function processes at least 6 bytes of
2583 this string, and decodes the bytes it finds according to the table
2584 below.  It stops decoding when it finds a byte not in the table,
2585 rather like @code{atoi}; if you have a buffer which has been broken into
2586 lines, you must be careful to skip over the end-of-line bytes.
2588 The decoded number is returned as a @code{long int} value.
2589 @end deftypefun
2591 The @code{l64a} and @code{a64l} functions use a base 64 encoding, in
2592 which each byte of an encoded string represents six bits of an
2593 input word.  These symbols are used for the base 64 digits:
2595 @multitable {xxxxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx}
2596 @item              @tab 0 @tab 1 @tab 2 @tab 3 @tab 4 @tab 5 @tab 6 @tab 7
2597 @item       0      @tab @code{.} @tab @code{/} @tab @code{0} @tab @code{1}
2598                    @tab @code{2} @tab @code{3} @tab @code{4} @tab @code{5}
2599 @item       8      @tab @code{6} @tab @code{7} @tab @code{8} @tab @code{9}
2600                    @tab @code{A} @tab @code{B} @tab @code{C} @tab @code{D}
2601 @item       16     @tab @code{E} @tab @code{F} @tab @code{G} @tab @code{H}
2602                    @tab @code{I} @tab @code{J} @tab @code{K} @tab @code{L}
2603 @item       24     @tab @code{M} @tab @code{N} @tab @code{O} @tab @code{P}
2604                    @tab @code{Q} @tab @code{R} @tab @code{S} @tab @code{T}
2605 @item       32     @tab @code{U} @tab @code{V} @tab @code{W} @tab @code{X}
2606                    @tab @code{Y} @tab @code{Z} @tab @code{a} @tab @code{b}
2607 @item       40     @tab @code{c} @tab @code{d} @tab @code{e} @tab @code{f}
2608                    @tab @code{g} @tab @code{h} @tab @code{i} @tab @code{j}
2609 @item       48     @tab @code{k} @tab @code{l} @tab @code{m} @tab @code{n}
2610                    @tab @code{o} @tab @code{p} @tab @code{q} @tab @code{r}
2611 @item       56     @tab @code{s} @tab @code{t} @tab @code{u} @tab @code{v}
2612                    @tab @code{w} @tab @code{x} @tab @code{y} @tab @code{z}
2613 @end multitable
2615 This encoding scheme is not standard.  There are some other encoding
2616 methods which are much more widely used (UU encoding, MIME encoding).
2617 Generally, it is better to use one of these encodings.
2619 @node Argz and Envz Vectors
2620 @section Argz and Envz Vectors
2622 @cindex argz vectors (string vectors)
2623 @cindex string vectors, null-byte separated
2624 @cindex argument vectors, null-byte separated
2625 @dfn{argz vectors} are vectors of strings in a contiguous block of
2626 memory, each element separated from its neighbors by null bytes
2627 (@code{'\0'}).
2629 @cindex envz vectors (environment vectors)
2630 @cindex environment vectors, null-byte separated
2631 @dfn{Envz vectors} are an extension of argz vectors where each element is a
2632 name-value pair, separated by a @code{'='} byte (as in a Unix
2633 environment).
2635 @menu
2636 * Argz Functions::              Operations on argz vectors.
2637 * Envz Functions::              Additional operations on environment vectors.
2638 @end menu
2640 @node Argz Functions, Envz Functions, , Argz and Envz Vectors
2641 @subsection Argz Functions
2643 Each argz vector is represented by a pointer to the first element, of
2644 type @code{char *}, and a size, of type @code{size_t}, both of which can
2645 be initialized to @code{0} to represent an empty argz vector.  All argz
2646 functions accept either a pointer and a size argument, or pointers to
2647 them, if they will be modified.
2649 The argz functions use @code{malloc}/@code{realloc} to allocate/grow
2650 argz vectors, and so any argz vector created using these functions may
2651 be freed by using @code{free}; conversely, any argz function that may
2652 grow a string expects that string to have been allocated using
2653 @code{malloc} (those argz functions that only examine their arguments or
2654 modify them in place will work on any sort of memory).
2655 @xref{Unconstrained Allocation}.
2657 All argz functions that do memory allocation have a return type of
2658 @code{error_t}, and return @code{0} for success, and @code{ENOMEM} if an
2659 allocation error occurs.
2661 @pindex argz.h
2662 These functions are declared in the standard include file @file{argz.h}.
2664 @deftypefun {error_t} argz_create (char *const @var{argv}[], char **@var{argz}, size_t *@var{argz_len})
2665 @standards{GNU, argz.h}
2666 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2667 The @code{argz_create} function converts the Unix-style argument vector
2668 @var{argv} (a vector of pointers to normal C strings, terminated by
2669 @code{(char *)0}; @pxref{Program Arguments}) into an argz vector with
2670 the same elements, which is returned in @var{argz} and @var{argz_len}.
2671 @end deftypefun
2673 @deftypefun {error_t} argz_create_sep (const char *@var{string}, int @var{sep}, char **@var{argz}, size_t *@var{argz_len})
2674 @standards{GNU, argz.h}
2675 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2676 The @code{argz_create_sep} function converts the string
2677 @var{string} into an argz vector (returned in @var{argz} and
2678 @var{argz_len}) by splitting it into elements at every occurrence of the
2679 byte @var{sep}.
2680 @end deftypefun
2682 @deftypefun {size_t} argz_count (const char *@var{argz}, size_t @var{argz_len})
2683 @standards{GNU, argz.h}
2684 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2685 Returns the number of elements in the argz vector @var{argz} and
2686 @var{argz_len}.
2687 @end deftypefun
2689 @deftypefun {void} argz_extract (const char *@var{argz}, size_t @var{argz_len}, char **@var{argv})
2690 @standards{GNU, argz.h}
2691 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2692 The @code{argz_extract} function converts the argz vector @var{argz} and
2693 @var{argz_len} into a Unix-style argument vector stored in @var{argv},
2694 by putting pointers to every element in @var{argz} into successive
2695 positions in @var{argv}, followed by a terminator of @code{0}.
2696 @var{Argv} must be pre-allocated with enough space to hold all the
2697 elements in @var{argz} plus the terminating @code{(char *)0}
2698 (@code{(argz_count (@var{argz}, @var{argz_len}) + 1) * sizeof (char *)}
2699 bytes should be enough).  Note that the string pointers stored into
2700 @var{argv} point into @var{argz}---they are not copies---and so
2701 @var{argz} must be copied if it will be changed while @var{argv} is
2702 still active.  This function is useful for passing the elements in
2703 @var{argz} to an exec function (@pxref{Executing a File}).
2704 @end deftypefun
2706 @deftypefun {void} argz_stringify (char *@var{argz}, size_t @var{len}, int @var{sep})
2707 @standards{GNU, argz.h}
2708 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2709 The @code{argz_stringify} converts @var{argz} into a normal string with
2710 the elements separated by the byte @var{sep}, by replacing each
2711 @code{'\0'} inside @var{argz} (except the last one, which terminates the
2712 string) with @var{sep}.  This is handy for printing @var{argz} in a
2713 readable manner.
2714 @end deftypefun
2716 @deftypefun {error_t} argz_add (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str})
2717 @standards{GNU, argz.h}
2718 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2719 @c Calls strlen and argz_append.
2720 The @code{argz_add} function adds the string @var{str} to the end of the
2721 argz vector @code{*@var{argz}}, and updates @code{*@var{argz}} and
2722 @code{*@var{argz_len}} accordingly.
2723 @end deftypefun
2725 @deftypefun {error_t} argz_add_sep (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str}, int @var{delim})
2726 @standards{GNU, argz.h}
2727 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2728 The @code{argz_add_sep} function is similar to @code{argz_add}, but
2729 @var{str} is split into separate elements in the result at occurrences of
2730 the byte @var{delim}.  This is useful, for instance, for
2731 adding the components of a Unix search path to an argz vector, by using
2732 a value of @code{':'} for @var{delim}.
2733 @end deftypefun
2735 @deftypefun {error_t} argz_append (char **@var{argz}, size_t *@var{argz_len}, const char *@var{buf}, size_t @var{buf_len})
2736 @standards{GNU, argz.h}
2737 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2738 The @code{argz_append} function appends @var{buf_len} bytes starting at
2739 @var{buf} to the argz vector @code{*@var{argz}}, reallocating
2740 @code{*@var{argz}} to accommodate it, and adding @var{buf_len} to
2741 @code{*@var{argz_len}}.
2742 @end deftypefun
2744 @deftypefun {void} argz_delete (char **@var{argz}, size_t *@var{argz_len}, char *@var{entry})
2745 @standards{GNU, argz.h}
2746 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2747 @c Calls free if no argument is left.
2748 If @var{entry} points to the beginning of one of the elements in the
2749 argz vector @code{*@var{argz}}, the @code{argz_delete} function will
2750 remove this entry and reallocate @code{*@var{argz}}, modifying
2751 @code{*@var{argz}} and @code{*@var{argz_len}} accordingly.  Note that as
2752 destructive argz functions usually reallocate their argz argument,
2753 pointers into argz vectors such as @var{entry} will then become invalid.
2754 @end deftypefun
2756 @deftypefun {error_t} argz_insert (char **@var{argz}, size_t *@var{argz_len}, char *@var{before}, const char *@var{entry})
2757 @standards{GNU, argz.h}
2758 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2759 @c Calls argz_add or realloc and memmove.
2760 The @code{argz_insert} function inserts the string @var{entry} into the
2761 argz vector @code{*@var{argz}} at a point just before the existing
2762 element pointed to by @var{before}, reallocating @code{*@var{argz}} and
2763 updating @code{*@var{argz}} and @code{*@var{argz_len}}.  If @var{before}
2764 is @code{0}, @var{entry} is added to the end instead (as if by
2765 @code{argz_add}).  Since the first element is in fact the same as
2766 @code{*@var{argz}}, passing in @code{*@var{argz}} as the value of
2767 @var{before} will result in @var{entry} being inserted at the beginning.
2768 @end deftypefun
2770 @deftypefun {char *} argz_next (const char *@var{argz}, size_t @var{argz_len}, const char *@var{entry})
2771 @standards{GNU, argz.h}
2772 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2773 The @code{argz_next} function provides a convenient way of iterating
2774 over the elements in the argz vector @var{argz}.  It returns a pointer
2775 to the next element in @var{argz} after the element @var{entry}, or
2776 @code{0} if there are no elements following @var{entry}.  If @var{entry}
2777 is @code{0}, the first element of @var{argz} is returned.
2779 This behavior suggests two styles of iteration:
2781 @smallexample
2782     char *entry = 0;
2783     while ((entry = argz_next (@var{argz}, @var{argz_len}, entry)))
2784       @var{action};
2785 @end smallexample
2787 (the double parentheses are necessary to make some C compilers shut up
2788 about what they consider a questionable @code{while}-test) and:
2790 @smallexample
2791     char *entry;
2792     for (entry = @var{argz};
2793          entry;
2794          entry = argz_next (@var{argz}, @var{argz_len}, entry))
2795       @var{action};
2796 @end smallexample
2798 Note that the latter depends on @var{argz} having a value of @code{0} if
2799 it is empty (rather than a pointer to an empty block of memory); this
2800 invariant is maintained for argz vectors created by the functions here.
2801 @end deftypefun
2803 @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}})
2804 @standards{GNU, argz.h}
2805 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2806 Replace any occurrences of the string @var{str} in @var{argz} with
2807 @var{with}, reallocating @var{argz} as necessary.  If
2808 @var{replace_count} is non-zero, @code{*@var{replace_count}} will be
2809 incremented by the number of replacements performed.
2810 @end deftypefun
2812 @node Envz Functions, , Argz Functions, Argz and Envz Vectors
2813 @subsection Envz Functions
2815 Envz vectors are just argz vectors with additional constraints on the form
2816 of each element; as such, argz functions can also be used on them, where it
2817 makes sense.
2819 Each element in an envz vector is a name-value pair, separated by a @code{'='}
2820 byte; if multiple @code{'='} bytes are present in an element, those
2821 after the first are considered part of the value, and treated like all other
2822 non-@code{'\0'} bytes.
2824 If @emph{no} @code{'='} bytes are present in an element, that element is
2825 considered the name of a ``null'' entry, as distinct from an entry with an
2826 empty value: @code{envz_get} will return @code{0} if given the name of null
2827 entry, whereas an entry with an empty value would result in a value of
2828 @code{""}; @code{envz_entry} will still find such entries, however.  Null
2829 entries can be removed with the @code{envz_strip} function.
2831 As with argz functions, envz functions that may allocate memory (and thus
2832 fail) have a return type of @code{error_t}, and return either @code{0} or
2833 @code{ENOMEM}.
2835 @pindex envz.h
2836 These functions are declared in the standard include file @file{envz.h}.
2838 @deftypefun {char *} envz_entry (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
2839 @standards{GNU, envz.h}
2840 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2841 The @code{envz_entry} function finds the entry in @var{envz} with the name
2842 @var{name}, and returns a pointer to the whole entry---that is, the argz
2843 element which begins with @var{name} followed by a @code{'='} byte.  If
2844 there is no entry with that name, @code{0} is returned.
2845 @end deftypefun
2847 @deftypefun {char *} envz_get (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
2848 @standards{GNU, envz.h}
2849 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2850 The @code{envz_get} function finds the entry in @var{envz} with the name
2851 @var{name} (like @code{envz_entry}), and returns a pointer to the value
2852 portion of that entry (following the @code{'='}).  If there is no entry with
2853 that name (or only a null entry), @code{0} is returned.
2854 @end deftypefun
2856 @deftypefun {error_t} envz_add (char **@var{envz}, size_t *@var{envz_len}, const char *@var{name}, const char *@var{value})
2857 @standards{GNU, envz.h}
2858 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2859 @c Calls envz_remove, which calls enz_entry and argz_delete, and then
2860 @c argz_add or equivalent code that reallocs and appends name=value.
2861 The @code{envz_add} function adds an entry to @code{*@var{envz}}
2862 (updating @code{*@var{envz}} and @code{*@var{envz_len}}) with the name
2863 @var{name}, and value @var{value}.  If an entry with the same name
2864 already exists in @var{envz}, it is removed first.  If @var{value} is
2865 @code{0}, then the new entry will be the special null type of entry
2866 (mentioned above).
2867 @end deftypefun
2869 @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})
2870 @standards{GNU, envz.h}
2871 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2872 The @code{envz_merge} function adds each entry in @var{envz2} to @var{envz},
2873 as if with @code{envz_add}, updating @code{*@var{envz}} and
2874 @code{*@var{envz_len}}.  If @var{override} is true, then values in @var{envz2}
2875 will supersede those with the same name in @var{envz}, otherwise not.
2877 Null entries are treated just like other entries in this respect, so a null
2878 entry in @var{envz} can prevent an entry of the same name in @var{envz2} from
2879 being added to @var{envz}, if @var{override} is false.
2880 @end deftypefun
2882 @deftypefun {void} envz_strip (char **@var{envz}, size_t *@var{envz_len})
2883 @standards{GNU, envz.h}
2884 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
2885 The @code{envz_strip} function removes any null entries from @var{envz},
2886 updating @code{*@var{envz}} and @code{*@var{envz_len}}.
2887 @end deftypefun
2889 @deftypefun {void} envz_remove (char **@var{envz}, size_t *@var{envz_len}, const char *@var{name})
2890 @standards{GNU, envz.h}
2891 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
2892 The @code{envz_remove} function removes an entry named @var{name} from
2893 @var{envz}, updating @code{*@var{envz}} and @code{*@var{envz_len}}.
2894 @end deftypefun
2896 @c FIXME this are undocumented:
2897 @c strcasecmp_l @safety{@mtsafe{}@assafe{}@acsafe{}} see strcasecmp