mirror of
				https://sourceware.org/git/glibc.git
				synced 2025-11-03 20:53:13 +03:00 
			
		
		
		
	2000-04-30 Ulrich Drepper <drepper@redhat.com> * manual/string.texi: Fix typo. * manual/terminal.texi: Document gtty and stty. Patch by Bryan Henderson <bryanh@giraffe-data.com>.
		
			
				
	
	
		
			1883 lines
		
	
	
		
			73 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			1883 lines
		
	
	
		
			73 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
@node String and Array Utilities, Character Set Handling, Character Handling, Top
 | 
						|
@c %MENU% Utilities for copying and comparing strings and arrays
 | 
						|
@chapter String and Array Utilities
 | 
						|
 | 
						|
Operations on strings (or arrays of characters) are an important part of
 | 
						|
many programs.  The GNU C library provides an extensive set of string
 | 
						|
utility functions, including functions for copying, concatenating,
 | 
						|
comparing, and searching strings.  Many of these functions can also
 | 
						|
operate on arbitrary regions of storage; for example, the @code{memcpy}
 | 
						|
function can be used to copy the contents of any kind of array.
 | 
						|
 | 
						|
It's fairly common for beginning C programmers to ``reinvent the wheel''
 | 
						|
by duplicating this functionality in their own code, but it pays to
 | 
						|
become familiar with the library functions and to make use of them,
 | 
						|
since this offers benefits in maintenance, efficiency, and portability.
 | 
						|
 | 
						|
For instance, you could easily compare one string to another in two
 | 
						|
lines of C code, but if you use the built-in @code{strcmp} function,
 | 
						|
you're less likely to make a mistake.  And, since these library
 | 
						|
functions are typically highly optimized, your program may run faster
 | 
						|
too.
 | 
						|
 | 
						|
@menu
 | 
						|
* Representation of Strings::   Introduction to basic concepts.
 | 
						|
* String/Array Conventions::    Whether to use a string function or an
 | 
						|
				 arbitrary array function.
 | 
						|
* String Length::               Determining the length of a string.
 | 
						|
* Copying and Concatenation::   Functions to copy the contents of strings
 | 
						|
				 and arrays.
 | 
						|
* String/Array Comparison::     Functions for byte-wise and character-wise
 | 
						|
				 comparison.
 | 
						|
* Collation Functions::         Functions for collating strings.
 | 
						|
* Search Functions::            Searching for a specific element or substring.
 | 
						|
* Finding Tokens in a String::  Splitting a string into tokens by looking
 | 
						|
				 for delimiters.
 | 
						|
* strfry::                      Function for flash-cooking a string.
 | 
						|
* Trivial Encryption::          Obscuring data.
 | 
						|
* Encode Binary Data::          Encoding and Decoding of Binary Data.
 | 
						|
* Argz and Envz Vectors::       Null-separated string vectors.
 | 
						|
@end menu
 | 
						|
 | 
						|
@node Representation of Strings
 | 
						|
@section Representation of Strings
 | 
						|
@cindex string, representation of
 | 
						|
 | 
						|
This section is a quick summary of string concepts for beginning C
 | 
						|
programmers.  It describes how character strings are represented in C
 | 
						|
and some common pitfalls.  If you are already familiar with this
 | 
						|
material, you can skip this section.
 | 
						|
 | 
						|
@cindex string
 | 
						|
@cindex null character
 | 
						|
A @dfn{string} is an array of @code{char} objects.  But string-valued
 | 
						|
variables are usually declared to be pointers of type @code{char *}.
 | 
						|
Such variables do not include space for the text of a string; that has
 | 
						|
to be stored somewhere else---in an array variable, a string constant,
 | 
						|
or dynamically allocated memory (@pxref{Memory Allocation}).  It's up to
 | 
						|
you to store the address of the chosen memory space into the pointer
 | 
						|
variable.  Alternatively you can store a @dfn{null pointer} in the
 | 
						|
pointer variable.  The null pointer does not point anywhere, so
 | 
						|
attempting to reference the string it points to gets an error.
 | 
						|
 | 
						|
By convention, a @dfn{null character}, @code{'\0'}, marks the end of a
 | 
						|
string.  For example, in testing to see whether the @code{char *}
 | 
						|
variable @var{p} points to a null character marking the end of a string,
 | 
						|
you can write @code{!*@var{p}} or @code{*@var{p} == '\0'}.
 | 
						|
 | 
						|
A null character is quite different conceptually from a null pointer,
 | 
						|
although both are represented by the integer @code{0}.
 | 
						|
 | 
						|
@cindex string literal
 | 
						|
@dfn{String literals} appear in C program source as strings of
 | 
						|
characters between double-quote characters (@samp{"}).  In @w{ISO C},
 | 
						|
string literals can also be formed by @dfn{string concatenation}:
 | 
						|
@code{"a" "b"} is the same as @code{"ab"}.  Modification of string
 | 
						|
literals is not allowed by the GNU C compiler, because literals
 | 
						|
are placed in read-only storage.
 | 
						|
 | 
						|
Character arrays that are declared @code{const} cannot be modified
 | 
						|
either.  It's generally good style to declare non-modifiable string
 | 
						|
pointers to be of type @code{const char *}, since this often allows the
 | 
						|
C compiler to detect accidental modifications as well as providing some
 | 
						|
amount of documentation about what your program intends to do with the
 | 
						|
string.
 | 
						|
 | 
						|
The amount of memory allocated for the character array may extend past
 | 
						|
the null character that normally marks the end of the string.  In this
 | 
						|
document, the term @dfn{allocated size} is always used to refer to the
 | 
						|
total amount of memory allocated for the string, while the term
 | 
						|
@dfn{length} refers to the number of characters up to (but not
 | 
						|
including) the terminating null character.
 | 
						|
@cindex length of string
 | 
						|
@cindex allocation size of string
 | 
						|
@cindex size of string
 | 
						|
@cindex string length
 | 
						|
@cindex string allocation
 | 
						|
 | 
						|
A notorious source of program bugs is trying to put more characters in a
 | 
						|
string than fit in its allocated size.  When writing code that extends
 | 
						|
strings or moves characters into a pre-allocated array, you should be
 | 
						|
very careful to keep track of the length of the text and make explicit
 | 
						|
checks for overflowing the array.  Many of the library functions
 | 
						|
@emph{do not} do this for you!  Remember also that you need to allocate
 | 
						|
an extra byte to hold the null character that marks the end of the
 | 
						|
string.
 | 
						|
 | 
						|
@node String/Array Conventions
 | 
						|
@section String and Array Conventions
 | 
						|
 | 
						|
This chapter describes both functions that work on arbitrary arrays or
 | 
						|
blocks of memory, and functions that are specific to null-terminated
 | 
						|
arrays of characters.
 | 
						|
 | 
						|
Functions that operate on arbitrary blocks of memory have names
 | 
						|
beginning with @samp{mem} (such as @code{memcpy}) and invariably take an
 | 
						|
argument which specifies the size (in bytes) of the block of memory to
 | 
						|
operate on.  The array arguments and return values for these functions
 | 
						|
have type @code{void *}, and as a matter of style, the elements of these
 | 
						|
arrays are referred to as ``bytes''.  You can pass any kind of pointer
 | 
						|
to these functions, and the @code{sizeof} operator is useful in
 | 
						|
computing the value for the size argument.
 | 
						|
 | 
						|
In contrast, functions that operate specifically on strings have names
 | 
						|
beginning with @samp{str} (such as @code{strcpy}) and look for a null
 | 
						|
character to terminate the string instead of requiring an explicit size
 | 
						|
argument to be passed.  (Some of these functions accept a specified
 | 
						|
maximum length, but they also check for premature termination with a
 | 
						|
null character.)  The array arguments and return values for these
 | 
						|
functions have type @code{char *}, and the array elements are referred
 | 
						|
to as ``characters''.
 | 
						|
 | 
						|
In many cases, there are both @samp{mem} and @samp{str} versions of a
 | 
						|
function.  The one that is more appropriate to use depends on the exact
 | 
						|
situation.  When your program is manipulating arbitrary arrays or blocks of
 | 
						|
storage, then you should always use the @samp{mem} functions.  On the
 | 
						|
other hand, when you are manipulating null-terminated strings it is
 | 
						|
usually more convenient to use the @samp{str} functions, unless you
 | 
						|
already know the length of the string in advance.
 | 
						|
 | 
						|
@node String Length
 | 
						|
@section String Length
 | 
						|
 | 
						|
You can get the length of a string using the @code{strlen} function.
 | 
						|
This function is declared in the header file @file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun size_t strlen (const char *@var{s})
 | 
						|
The @code{strlen} function returns the length of the null-terminated
 | 
						|
string @var{s}.  (In other words, it returns the offset of the terminating
 | 
						|
null character within the array.)
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strlen ("hello, world")
 | 
						|
    @result{} 12
 | 
						|
@end smallexample
 | 
						|
 | 
						|
When applied to a character array, the @code{strlen} function returns
 | 
						|
the length of the string stored there, not its allocated size.  You can
 | 
						|
get the allocated size of the character array that holds a string using
 | 
						|
the @code{sizeof} operator:
 | 
						|
 | 
						|
@smallexample
 | 
						|
char string[32] = "hello, world";
 | 
						|
sizeof (string)
 | 
						|
    @result{} 32
 | 
						|
strlen (string)
 | 
						|
    @result{} 12
 | 
						|
@end smallexample
 | 
						|
 | 
						|
But beware, this will not work unless @var{string} is the character
 | 
						|
array itself, not a pointer to it.  For example:
 | 
						|
 | 
						|
@smallexample
 | 
						|
char string[32] = "hello, world";
 | 
						|
char *ptr = string;
 | 
						|
sizeof (string)
 | 
						|
    @result{} 32
 | 
						|
sizeof (ptr)
 | 
						|
    @result{} 4  /* @r{(on a machine with 4 byte pointers)} */
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This is an easy mistake to make when you are working with functions that
 | 
						|
take string arguments; those arguments are always pointers, not arrays.
 | 
						|
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun size_t strnlen (const char *@var{s}, size_t @var{maxlen})
 | 
						|
The @code{strnlen} function returns the length of the null-terminated
 | 
						|
string @var{s} is this length is smaller than @var{maxlen}.  Otherwise
 | 
						|
it returns @var{maxlen}.  Therefore this function is equivalent to
 | 
						|
@code{(strlen (@var{s}) < n ? strlen (@var{s}) : @var{maxlen})} but it
 | 
						|
is more efficient.
 | 
						|
 | 
						|
@smallexample
 | 
						|
char string[32] = "hello, world";
 | 
						|
strnlen (string, 32)
 | 
						|
    @result{} 12
 | 
						|
strnlen (string, 5)
 | 
						|
    @result{} 5
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This function is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node Copying and Concatenation
 | 
						|
@section Copying and Concatenation
 | 
						|
 | 
						|
You can use the functions described in this section to copy the contents
 | 
						|
of strings and arrays, or to append the contents of one string to
 | 
						|
another.  These functions are declared in the header file
 | 
						|
@file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
@cindex copying strings and arrays
 | 
						|
@cindex string copy functions
 | 
						|
@cindex array copy functions
 | 
						|
@cindex concatenating strings
 | 
						|
@cindex string concatenation functions
 | 
						|
 | 
						|
A helpful way to remember the ordering of the arguments to the functions
 | 
						|
in this section is that it corresponds to an assignment expression, with
 | 
						|
the destination array specified to the left of the source array.  All
 | 
						|
of these functions return the address of the destination array.
 | 
						|
 | 
						|
Most of these functions do not work properly if the source and
 | 
						|
destination arrays overlap.  For example, if the beginning of the
 | 
						|
destination array overlaps the end of the source array, the original
 | 
						|
contents of that part of the source array may get overwritten before it
 | 
						|
is copied.  Even worse, in the case of the string functions, the null
 | 
						|
character marking the end of the string may be lost, and the copy
 | 
						|
function might get stuck in a loop trashing all the memory allocated to
 | 
						|
your program.
 | 
						|
 | 
						|
All functions that have problems copying between overlapping arrays are
 | 
						|
explicitly identified in this manual.  In addition to functions in this
 | 
						|
section, there are a few others like @code{sprintf} (@pxref{Formatted
 | 
						|
Output Functions}) and @code{scanf} (@pxref{Formatted Input
 | 
						|
Functions}).
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {void *} memcpy (void *@var{to}, const void *@var{from}, size_t @var{size})
 | 
						|
The @code{memcpy} function copies @var{size} bytes from the object
 | 
						|
beginning at @var{from} into the object beginning at @var{to}.  The
 | 
						|
behavior of this function is undefined if the two arrays @var{to} and
 | 
						|
@var{from} overlap; use @code{memmove} instead if overlapping is possible.
 | 
						|
 | 
						|
The value returned by @code{memcpy} is the value of @var{to}.
 | 
						|
 | 
						|
Here is an example of how you might use @code{memcpy} to copy the
 | 
						|
contents of an array:
 | 
						|
 | 
						|
@smallexample
 | 
						|
struct foo *oldarray, *newarray;
 | 
						|
int arraysize;
 | 
						|
@dots{}
 | 
						|
memcpy (new, old, arraysize * sizeof (struct foo));
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void *} mempcpy (void *@var{to}, const void *@var{from}, size_t @var{size})
 | 
						|
The @code{mempcpy} function is nearly identical to the @code{memcpy}
 | 
						|
function.  It copies @var{size} bytes from the object beginning at
 | 
						|
@code{from} into the object pointed to by @var{to}.  But instead of
 | 
						|
returning the value of @var{to} it returns a pointer to the byte
 | 
						|
following the last written byte in the object beginning at @var{to}.
 | 
						|
I.e., the value is @code{((void *) ((char *) @var{to} + @var{size}))}.
 | 
						|
 | 
						|
This function is useful in situations where a number of objects shall be
 | 
						|
copied to consecutive memory positions.
 | 
						|
 | 
						|
@smallexample
 | 
						|
void *
 | 
						|
combine (void *o1, size_t s1, void *o2, size_t s2)
 | 
						|
@{
 | 
						|
  void *result = malloc (s1 + s2);
 | 
						|
  if (result != NULL)
 | 
						|
    mempcpy (mempcpy (result, o1, s1), o2, s2);
 | 
						|
  return result;
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This function is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {void *} memmove (void *@var{to}, const void *@var{from}, size_t @var{size})
 | 
						|
@code{memmove} copies the @var{size} bytes at @var{from} into the
 | 
						|
@var{size} bytes at @var{to}, even if those two blocks of space
 | 
						|
overlap.  In the case of overlap, @code{memmove} is careful to copy the
 | 
						|
original values of the bytes in the block at @var{from}, including those
 | 
						|
bytes which also belong to the block at @var{to}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment SVID
 | 
						|
@deftypefun {void *} memccpy (void *@var{to}, const void *@var{from}, int @var{c}, size_t @var{size})
 | 
						|
This function copies no more than @var{size} bytes from @var{from} to
 | 
						|
@var{to}, stopping if a byte matching @var{c} is found.  The return
 | 
						|
value is a pointer into @var{to} one byte past where @var{c} was copied,
 | 
						|
or a null pointer if no byte matching @var{c} appeared in the first
 | 
						|
@var{size} bytes of @var{from}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {void *} memset (void *@var{block}, int @var{c}, size_t @var{size})
 | 
						|
This function copies the value of @var{c} (converted to an
 | 
						|
@code{unsigned char}) into each of the first @var{size} bytes of the
 | 
						|
object beginning at @var{block}.  It returns the value of @var{block}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strcpy (char *@var{to}, const char *@var{from})
 | 
						|
This copies characters from the string @var{from} (up to and including
 | 
						|
the terminating null character) into the string @var{to}.  Like
 | 
						|
@code{memcpy}, this function has undefined results if the strings
 | 
						|
overlap.  The return value is the value of @var{to}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strncpy (char *@var{to}, const char *@var{from}, size_t @var{size})
 | 
						|
This function is similar to @code{strcpy} but always copies exactly
 | 
						|
@var{size} characters into @var{to}.
 | 
						|
 | 
						|
If the length of @var{from} is more than @var{size}, then @code{strncpy}
 | 
						|
copies just the first @var{size} characters.  Note that in this case
 | 
						|
there is no null terminator written into @var{to}.
 | 
						|
 | 
						|
If the length of @var{from} is less than @var{size}, then @code{strncpy}
 | 
						|
copies all of @var{from}, followed by enough null characters to add up
 | 
						|
to @var{size} characters in all.  This behavior is rarely useful, but it
 | 
						|
is specified by the @w{ISO C} standard.
 | 
						|
 | 
						|
The behavior of @code{strncpy} is undefined if the strings overlap.
 | 
						|
 | 
						|
Using @code{strncpy} as opposed to @code{strcpy} is a way to avoid bugs
 | 
						|
relating to writing past the end of the allocated space for @var{to}.
 | 
						|
However, it can also make your program much slower in one common case:
 | 
						|
copying a string which is probably small into a potentially large buffer.
 | 
						|
In this case, @var{size} may be large, and when it is, @code{strncpy} will
 | 
						|
waste a considerable amount of time copying null characters.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment SVID
 | 
						|
@deftypefun {char *} strdup (const char *@var{s})
 | 
						|
This function copies the null-terminated string @var{s} into a newly
 | 
						|
allocated string.  The string is allocated using @code{malloc}; see
 | 
						|
@ref{Unconstrained Allocation}.  If @code{malloc} cannot allocate space
 | 
						|
for the new string, @code{strdup} returns a null pointer.  Otherwise it
 | 
						|
returns a pointer to the new string.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} strndup (const char *@var{s}, size_t @var{size})
 | 
						|
This function is similar to @code{strdup} but always copies at most
 | 
						|
@var{size} characters into the newly allocated string.
 | 
						|
 | 
						|
If the length of @var{s} is more than @var{size}, then @code{strndup}
 | 
						|
copies just the first @var{size} characters and adds a closing null
 | 
						|
terminator.  Otherwise all characters are copied and the string is
 | 
						|
terminated.
 | 
						|
 | 
						|
This function is different to @code{strncpy} in that it always
 | 
						|
terminates the destination string.
 | 
						|
 | 
						|
@code{strndup} is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment Unknown origin
 | 
						|
@deftypefun {char *} stpcpy (char *@var{to}, const char *@var{from})
 | 
						|
This function is like @code{strcpy}, except that it returns a pointer to
 | 
						|
the end of the string @var{to} (that is, the address of the terminating
 | 
						|
null character) rather than the beginning.
 | 
						|
 | 
						|
For example, this program uses @code{stpcpy} to concatenate @samp{foo}
 | 
						|
and @samp{bar} to produce @samp{foobar}, which it then prints.
 | 
						|
 | 
						|
@smallexample
 | 
						|
@include stpcpy.c.texi
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This function is not part of the ISO or POSIX standards, and is not
 | 
						|
customary on Unix systems, but we did not invent it either.  Perhaps it
 | 
						|
comes from MS-DOG.
 | 
						|
 | 
						|
Its behavior is undefined if the strings overlap.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} stpncpy (char *@var{to}, const char *@var{from}, size_t @var{size})
 | 
						|
This function is similar to @code{stpcpy} but copies always exactly
 | 
						|
@var{size} characters into @var{to}.
 | 
						|
 | 
						|
If the length of @var{from} is more then @var{size}, then @code{stpncpy}
 | 
						|
copies just the first @var{size} characters and returns a pointer to the
 | 
						|
character directly following the one which was copied last.  Note that in
 | 
						|
this case there is no null terminator written into @var{to}.
 | 
						|
 | 
						|
If the length of @var{from} is less than @var{size}, then @code{stpncpy}
 | 
						|
copies all of @var{from}, followed by enough null characters to add up
 | 
						|
to @var{size} characters in all.  This behaviour is rarely useful, but it
 | 
						|
is implemented to be useful in contexts where this behaviour of the
 | 
						|
@code{strncpy} is used.  @code{stpncpy} returns a pointer to the
 | 
						|
@emph{first} written null character.
 | 
						|
 | 
						|
This function is not part of ISO or POSIX but was found useful while
 | 
						|
developing the GNU C Library itself.
 | 
						|
 | 
						|
Its behaviour is undefined if the strings overlap.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefn {Macro} {char *} strdupa (const char *@var{s})
 | 
						|
This macro is similar to @code{strdup} but allocates the new string
 | 
						|
using @code{alloca} instead of @code{malloc} (@pxref{Variable Size
 | 
						|
Automatic}).  This means of course the returned string has the same
 | 
						|
limitations as any block of memory allocated using @code{alloca}.
 | 
						|
 | 
						|
For obvious reasons @code{strdupa} is implemented only as a macro;
 | 
						|
you cannot get the address of this function.  Despite this limitation
 | 
						|
it is a useful function.  The following code shows a situation where
 | 
						|
using @code{malloc} would be a lot more expensive.
 | 
						|
 | 
						|
@smallexample
 | 
						|
@include strdupa.c.texi
 | 
						|
@end smallexample
 | 
						|
 | 
						|
Please note that calling @code{strtok} using @var{path} directly is
 | 
						|
invalid.
 | 
						|
 | 
						|
This function is only available if GNU CC is used.
 | 
						|
@end deftypefn
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefn {Macro} {char *} strndupa (const char *@var{s}, size_t @var{size})
 | 
						|
This function is similar to @code{strndup} but like @code{strdupa} it
 | 
						|
allocates the new string using @code{alloca}
 | 
						|
@pxref{Variable Size Automatic}.  The same advantages and limitations
 | 
						|
of @code{strdupa} are valid for @code{strndupa}, too.
 | 
						|
 | 
						|
This function is implemented only as a macro, just like @code{strdupa}.
 | 
						|
 | 
						|
@code{strndupa} is only available if GNU CC is used.
 | 
						|
@end deftypefn
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strcat (char *@var{to}, const char *@var{from})
 | 
						|
The @code{strcat} function is similar to @code{strcpy}, except that the
 | 
						|
characters from @var{from} are concatenated or appended to the end of
 | 
						|
@var{to}, instead of overwriting it.  That is, the first character from
 | 
						|
@var{from} overwrites the null character marking the end of @var{to}.
 | 
						|
 | 
						|
An equivalent definition for @code{strcat} would be:
 | 
						|
 | 
						|
@smallexample
 | 
						|
char *
 | 
						|
strcat (char *to, const char *from)
 | 
						|
@{
 | 
						|
  strcpy (to + strlen (to), from);
 | 
						|
  return to;
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This function has undefined results if the strings overlap.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Programmers using the @code{strcat} function (or the following
 | 
						|
@code{strncat} function for that matter) can easily be recognized as
 | 
						|
lazy.  In almost all situations the lengths of the participating strings
 | 
						|
are known.  Or at least, one could know them if one keeps track of the
 | 
						|
results of the various function calls.  But then it is very inefficient
 | 
						|
to use @code{strcat}.  A lot of time is wasted finding the end of the
 | 
						|
destination string so that the actual copying can start.  This is a
 | 
						|
common example:
 | 
						|
 | 
						|
@cindex __va_copy
 | 
						|
@cindex va_copy
 | 
						|
@smallexample
 | 
						|
/* @r{This function concatenates arbitrarily many strings.  The last}
 | 
						|
   @r{parameter must be @code{NULL}.}  */
 | 
						|
char *
 | 
						|
concat (const char *str, ...)
 | 
						|
@{
 | 
						|
  va_list ap, ap2;
 | 
						|
  size_t total = 1;
 | 
						|
  const char *s;
 | 
						|
  char *result;
 | 
						|
 | 
						|
  va_start (ap, str);
 | 
						|
  /* @r{Actually @code{va_copy}, but this is the name more gcc versions}
 | 
						|
     @r{understand.}  */
 | 
						|
  __va_copy (ap2, ap);
 | 
						|
 | 
						|
  /* @r{Determine how much space we need.}  */
 | 
						|
  for (s = str; s != NULL; s = va_arg (ap, const char *))
 | 
						|
    total += strlen (s);
 | 
						|
 | 
						|
  va_end (ap);
 | 
						|
 | 
						|
  result = (char *) malloc (total);
 | 
						|
  if (result != NULL)
 | 
						|
    @{
 | 
						|
      result[0] = '\0';
 | 
						|
 | 
						|
      /* @r{Copy the strings.}  */
 | 
						|
      for (s = str; s != NULL; s = va_arg (ap2, const char *))
 | 
						|
        strcat (result, s);
 | 
						|
    @}
 | 
						|
 | 
						|
  va_end (ap2);
 | 
						|
 | 
						|
  return result;
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This looks quite simple, especially the second loop where the strings
 | 
						|
are actually copied.  But these innocent lines hide a major performance
 | 
						|
penalty.  Just imagine that ten strings of 100 bytes each have to be
 | 
						|
concatenated.  For the second string we search the already stored 100
 | 
						|
bytes for the end of the string so that we can append the next string.
 | 
						|
For all strings in total the comparisons necessary to find the end of
 | 
						|
the intermediate results sums up to 5500!  If we combine the copying
 | 
						|
with the search for the allocation we can write this function more
 | 
						|
efficient:
 | 
						|
 | 
						|
@smallexample
 | 
						|
char *
 | 
						|
concat (const char *str, ...)
 | 
						|
@{
 | 
						|
  va_list ap;
 | 
						|
  size_t allocated = 100;
 | 
						|
  char *result = (char *) malloc (allocated);
 | 
						|
  char *wp;
 | 
						|
 | 
						|
  if (allocated != NULL)
 | 
						|
    @{
 | 
						|
      char *newp;
 | 
						|
 | 
						|
      va_start (ap, atr);
 | 
						|
 | 
						|
      wp = result;
 | 
						|
      for (s = str; s != NULL; s = va_arg (ap, const char *))
 | 
						|
        @{
 | 
						|
          size_t len = strlen (s);
 | 
						|
 | 
						|
          /* @r{Resize the allocated memory if necessary.}  */
 | 
						|
          if (wp + len + 1 > result + allocated)
 | 
						|
            @{
 | 
						|
              allocated = (allocated + len) * 2;
 | 
						|
              newp = (char *) realloc (result, allocated);
 | 
						|
              if (newp == NULL)
 | 
						|
                @{
 | 
						|
                  free (result);
 | 
						|
                  return NULL;
 | 
						|
                @}
 | 
						|
              wp = newp + (wp - result);
 | 
						|
              result = newp;
 | 
						|
            @}
 | 
						|
 | 
						|
          wp = mempcpy (wp, s, len);
 | 
						|
        @}
 | 
						|
 | 
						|
      /* @r{Terminate the result string.}  */
 | 
						|
      *wp++ = '\0';
 | 
						|
 | 
						|
      /* @r{Resize memory to the optimal size.}  */
 | 
						|
      newp = realloc (result, wp - result);
 | 
						|
      if (newp != NULL)
 | 
						|
        result = newp;
 | 
						|
 | 
						|
      va_end (ap);
 | 
						|
    @}
 | 
						|
 | 
						|
  return result;
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
With a bit more knowledge about the input strings one could fine-tune
 | 
						|
the memory allocation.  The difference we are pointing to here is that
 | 
						|
we don't use @code{strcat} anymore.  We always keep track of the length
 | 
						|
of the current intermediate result so we can safe us the search for the
 | 
						|
end of the string and use @code{mempcpy}.  Please note that we also
 | 
						|
don't use @code{stpcpy} which might seem more natural since we handle
 | 
						|
with strings.  But this is not necessary since we already know the
 | 
						|
length of the string and therefore can use the faster memory copying
 | 
						|
function.
 | 
						|
 | 
						|
Whenever a programmer feels the need to use @code{strcat} she or he
 | 
						|
should think twice and look through the program whether the code cannot
 | 
						|
be rewritten to take advantage of already calculated results.  Again: it
 | 
						|
is almost always unnecessary to use @code{strcat}.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strncat (char *@var{to}, const char *@var{from}, size_t @var{size})
 | 
						|
This function is like @code{strcat} except that not more than @var{size}
 | 
						|
characters from @var{from} are appended to the end of @var{to}.  A
 | 
						|
single null character is also always appended to @var{to}, so the total
 | 
						|
allocated size of @var{to} must be at least @code{@var{size} + 1} bytes
 | 
						|
longer than its initial length.
 | 
						|
 | 
						|
The @code{strncat} function could be implemented like this:
 | 
						|
 | 
						|
@smallexample
 | 
						|
@group
 | 
						|
char *
 | 
						|
strncat (char *to, const char *from, size_t size)
 | 
						|
@{
 | 
						|
  strncpy (to + strlen (to), from, size);
 | 
						|
  return to;
 | 
						|
@}
 | 
						|
@end group
 | 
						|
@end smallexample
 | 
						|
 | 
						|
The behavior of @code{strncat} is undefined if the strings overlap.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Here is an example showing the use of @code{strncpy} and @code{strncat}.
 | 
						|
Notice how, in the call to @code{strncat}, the @var{size} parameter
 | 
						|
is computed to avoid overflowing the character array @code{buffer}.
 | 
						|
 | 
						|
@smallexample
 | 
						|
@include strncat.c.texi
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@noindent
 | 
						|
The output produced by this program looks like:
 | 
						|
 | 
						|
@smallexample
 | 
						|
hello
 | 
						|
hello, wo
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun void bcopy (const void *@var{from}, void *@var{to}, size_t @var{size})
 | 
						|
This is a partially obsolete alternative for @code{memmove}, derived from
 | 
						|
BSD.  Note that it is not quite equivalent to @code{memmove}, because the
 | 
						|
arguments are not in the same order and there is no return value.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun void bzero (void *@var{block}, size_t @var{size})
 | 
						|
This is a partially obsolete alternative for @code{memset}, derived from
 | 
						|
BSD.  Note that it is not as general as @code{memset}, because the only
 | 
						|
value it can store is zero.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node String/Array Comparison
 | 
						|
@section String/Array Comparison
 | 
						|
@cindex comparing strings and arrays
 | 
						|
@cindex string comparison functions
 | 
						|
@cindex array comparison functions
 | 
						|
@cindex predicates on strings
 | 
						|
@cindex predicates on arrays
 | 
						|
 | 
						|
You can use the functions in this section to perform comparisons on the
 | 
						|
contents of strings and arrays.  As well as checking for equality, these
 | 
						|
functions can also be used as the ordering functions for sorting
 | 
						|
operations.  @xref{Searching and Sorting}, for an example of this.
 | 
						|
 | 
						|
Unlike most comparison operations in C, the string comparison functions
 | 
						|
return a nonzero value if the strings are @emph{not} equivalent rather
 | 
						|
than if they are.  The sign of the value indicates the relative ordering
 | 
						|
of the first characters in the strings that are not equivalent:  a
 | 
						|
negative value indicates that the first string is ``less'' than the
 | 
						|
second, while a positive value indicates that the first string is
 | 
						|
``greater''.
 | 
						|
 | 
						|
The most common use of these functions is to check only for equality.
 | 
						|
This is canonically done with an expression like @w{@samp{! strcmp (s1, s2)}}.
 | 
						|
 | 
						|
All of these functions are declared in the header file @file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun int memcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
 | 
						|
The function @code{memcmp} compares the @var{size} bytes of memory
 | 
						|
beginning at @var{a1} against the @var{size} bytes of memory beginning
 | 
						|
at @var{a2}.  The value returned has the same sign as the difference
 | 
						|
between the first differing pair of bytes (interpreted as @code{unsigned
 | 
						|
char} objects, then promoted to @code{int}).
 | 
						|
 | 
						|
If the contents of the two blocks are equal, @code{memcmp} returns
 | 
						|
@code{0}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
On arbitrary arrays, the @code{memcmp} function is mostly useful for
 | 
						|
testing equality.  It usually isn't meaningful to do byte-wise ordering
 | 
						|
comparisons on arrays of things other than bytes.  For example, a
 | 
						|
byte-wise comparison on the bytes that make up floating-point numbers
 | 
						|
isn't likely to tell you anything about the relationship between the
 | 
						|
values of the floating-point numbers.
 | 
						|
 | 
						|
You should also be careful about using @code{memcmp} to compare objects
 | 
						|
that can contain ``holes'', such as the padding inserted into structure
 | 
						|
objects to enforce alignment requirements, extra space at the end of
 | 
						|
unions, and extra characters at the ends of strings whose length is less
 | 
						|
than their allocated size.  The contents of these ``holes'' are
 | 
						|
indeterminate and may cause strange behavior when performing byte-wise
 | 
						|
comparisons.  For more predictable results, perform an explicit
 | 
						|
component-wise comparison.
 | 
						|
 | 
						|
For example, given a structure type definition like:
 | 
						|
 | 
						|
@smallexample
 | 
						|
struct foo
 | 
						|
  @{
 | 
						|
    unsigned char tag;
 | 
						|
    union
 | 
						|
      @{
 | 
						|
        double f;
 | 
						|
        long i;
 | 
						|
        char *p;
 | 
						|
      @} value;
 | 
						|
  @};
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@noindent
 | 
						|
you are better off writing a specialized comparison function to compare
 | 
						|
@code{struct foo} objects instead of comparing them with @code{memcmp}.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun int strcmp (const char *@var{s1}, const char *@var{s2})
 | 
						|
The @code{strcmp} function compares the string @var{s1} against
 | 
						|
@var{s2}, returning a value that has the same sign as the difference
 | 
						|
between the first differing pair of characters (interpreted as
 | 
						|
@code{unsigned char} objects, then promoted to @code{int}).
 | 
						|
 | 
						|
If the two strings are equal, @code{strcmp} returns @code{0}.
 | 
						|
 | 
						|
A consequence of the ordering used by @code{strcmp} is that if @var{s1}
 | 
						|
is an initial substring of @var{s2}, then @var{s1} is considered to be
 | 
						|
``less than'' @var{s2}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun int strcasecmp (const char *@var{s1}, const char *@var{s2})
 | 
						|
This function is like @code{strcmp}, except that differences in case are
 | 
						|
ignored.  How uppercase and lowercase characters are related is
 | 
						|
determined by the currently selected locale.  In the standard @code{"C"}
 | 
						|
locale the characters @"A and @"a do not match but in a locale which
 | 
						|
regards these characters as parts of the alphabet they do match.
 | 
						|
 | 
						|
@noindent
 | 
						|
@code{strcasecmp} is derived from BSD.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun int strncasecmp (const char *@var{s1}, const char *@var{s2}, size_t @var{n})
 | 
						|
This function is like @code{strncmp}, except that differences in case
 | 
						|
are ignored.  Like @code{strcasecmp}, it is locale dependent how
 | 
						|
uppercase and lowercase characters are related.
 | 
						|
 | 
						|
@noindent
 | 
						|
@code{strncasecmp} is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun int strncmp (const char *@var{s1}, const char *@var{s2}, size_t @var{size})
 | 
						|
This function is the similar to @code{strcmp}, except that no more than
 | 
						|
@var{size} characters are compared.  In other words, if the two strings are
 | 
						|
the same in their first @var{size} characters, the return value is zero.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Here are some examples showing the use of @code{strcmp} and @code{strncmp}.
 | 
						|
These examples assume the use of the ASCII character set.  (If some
 | 
						|
other character set---say, EBCDIC---is used instead, then the glyphs
 | 
						|
are associated with different numeric codes, and the return values
 | 
						|
and ordering may differ.)
 | 
						|
 | 
						|
@smallexample
 | 
						|
strcmp ("hello", "hello")
 | 
						|
    @result{} 0    /* @r{These two strings are the same.} */
 | 
						|
strcmp ("hello", "Hello")
 | 
						|
    @result{} 32   /* @r{Comparisons are case-sensitive.} */
 | 
						|
strcmp ("hello", "world")
 | 
						|
    @result{} -15  /* @r{The character @code{'h'} comes before @code{'w'}.} */
 | 
						|
strcmp ("hello", "hello, world")
 | 
						|
    @result{} -44  /* @r{Comparing a null character against a comma.} */
 | 
						|
strncmp ("hello", "hello, world", 5)
 | 
						|
    @result{} 0    /* @r{The initial 5 characters are the same.} */
 | 
						|
strncmp ("hello, world", "hello, stupid world!!!", 5)
 | 
						|
    @result{} 0    /* @r{The initial 5 characters are the same.} */
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun int strverscmp (const char *@var{s1}, const char *@var{s2})
 | 
						|
The @code{strverscmp} function compares the string @var{s1} against
 | 
						|
@var{s2}, considering them as holding indices/version numbers.  Return
 | 
						|
value follows the same conventions as found in the @code{strverscmp}
 | 
						|
function.  In fact, if @var{s1} and @var{s2} contain no digits,
 | 
						|
@code{strverscmp} behaves like @code{strcmp}.
 | 
						|
 | 
						|
Basically, we compare strings normally (character by character), until
 | 
						|
we find a digit in each string - then we enter a special comparison
 | 
						|
mode, where each sequence of digits is taken as a whole.  If we reach the
 | 
						|
end of these two parts without noticing a difference, we return to the
 | 
						|
standard comparison mode.  There are two types of numeric parts:
 | 
						|
"integral" and "fractional" (those  begin with a '0'). The types
 | 
						|
of the numeric parts affect the way we sort them:
 | 
						|
 | 
						|
@itemize @bullet
 | 
						|
@item
 | 
						|
integral/integral: we compare values as you would expect.
 | 
						|
 | 
						|
@item
 | 
						|
fractional/integral: the fractional part is less than the integral one.
 | 
						|
Again, no surprise.
 | 
						|
 | 
						|
@item
 | 
						|
fractional/fractional: the things become a bit more complex.
 | 
						|
If the common prefix contains only leading zeroes, the longest part is less
 | 
						|
than the other one; else the comparison behaves normally.
 | 
						|
@end itemize
 | 
						|
 | 
						|
@smallexample
 | 
						|
strverscmp ("no digit", "no digit")
 | 
						|
    @result{} 0    /* @r{same behaviour as strcmp.} */
 | 
						|
strverscmp ("item#99", "item#100")
 | 
						|
    @result{} <0   /* @r{same prefix, but 99 < 100.} */
 | 
						|
strverscmp ("alpha1", "alpha001")
 | 
						|
    @result{} >0   /* @r{fractional part inferior to integral one.} */
 | 
						|
strverscmp ("part1_f012", "part1_f01")
 | 
						|
    @result{} >0   /* @r{two fractional parts.} */
 | 
						|
strverscmp ("foo.009", "foo.0")
 | 
						|
    @result{} <0   /* @r{idem, but with leading zeroes only.} */
 | 
						|
@end smallexample
 | 
						|
 | 
						|
This function is especially useful when dealing with filename sorting,
 | 
						|
because filenames frequently hold indices/version numbers.
 | 
						|
 | 
						|
@code{strverscmp} is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun int bcmp (const void *@var{a1}, const void *@var{a2}, size_t @var{size})
 | 
						|
This is an obsolete alias for @code{memcmp}, derived from BSD.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node Collation Functions
 | 
						|
@section Collation Functions
 | 
						|
 | 
						|
@cindex collating strings
 | 
						|
@cindex string collation functions
 | 
						|
 | 
						|
In some locales, the conventions for lexicographic ordering differ from
 | 
						|
the strict numeric ordering of character codes.  For example, in Spanish
 | 
						|
most glyphs with diacritical marks such as accents are not considered
 | 
						|
distinct letters for the purposes of collation.  On the other hand, the
 | 
						|
two-character sequence @samp{ll} is treated as a single letter that is
 | 
						|
collated immediately after @samp{l}.
 | 
						|
 | 
						|
You can use the functions @code{strcoll} and @code{strxfrm} (declared in
 | 
						|
the header file @file{string.h}) to compare strings using a collation
 | 
						|
ordering appropriate for the current locale.  The locale used by these
 | 
						|
functions in particular can be specified by setting the locale for the
 | 
						|
@code{LC_COLLATE} category; see @ref{Locales}.
 | 
						|
@pindex string.h
 | 
						|
 | 
						|
In the standard C locale, the collation sequence for @code{strcoll} is
 | 
						|
the same as that for @code{strcmp}.
 | 
						|
 | 
						|
Effectively, the way these functions work is by applying a mapping to
 | 
						|
transform the characters in a string to a byte sequence that represents
 | 
						|
the string's position in the collating sequence of the current locale.
 | 
						|
Comparing two such byte sequences in a simple fashion is equivalent to
 | 
						|
comparing the strings with the locale's collating sequence.
 | 
						|
 | 
						|
The function @code{strcoll} performs this translation implicitly, in
 | 
						|
order to do one comparison.  By contrast, @code{strxfrm} performs the
 | 
						|
mapping explicitly.  If you are making multiple comparisons using the
 | 
						|
same string or set of strings, it is likely to be more efficient to use
 | 
						|
@code{strxfrm} to transform all the strings just once, and subsequently
 | 
						|
compare the transformed strings with @code{strcmp}.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun int strcoll (const char *@var{s1}, const char *@var{s2})
 | 
						|
The @code{strcoll} function is similar to @code{strcmp} but uses the
 | 
						|
collating sequence of the current locale for collation (the
 | 
						|
@code{LC_COLLATE} locale).
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Here is an example of sorting an array of strings, using @code{strcoll}
 | 
						|
to compare them.  The actual sort algorithm is not written here; it
 | 
						|
comes from @code{qsort} (@pxref{Array Sort Function}).  The job of the
 | 
						|
code shown here is to say how to compare the strings while sorting them.
 | 
						|
(Later on in this section, we will show a way to do this more
 | 
						|
efficiently using @code{strxfrm}.)
 | 
						|
 | 
						|
@smallexample
 | 
						|
/* @r{This is the comparison function used with @code{qsort}.} */
 | 
						|
 | 
						|
int
 | 
						|
compare_elements (char **p1, char **p2)
 | 
						|
@{
 | 
						|
  return strcoll (*p1, *p2);
 | 
						|
@}
 | 
						|
 | 
						|
/* @r{This is the entry point---the function to sort}
 | 
						|
   @r{strings using the locale's collating sequence.} */
 | 
						|
 | 
						|
void
 | 
						|
sort_strings (char **array, int nstrings)
 | 
						|
@{
 | 
						|
  /* @r{Sort @code{temp_array} by comparing the strings.} */
 | 
						|
  qsort (array, nstrings,
 | 
						|
         sizeof (char *), compare_elements);
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@cindex converting string to collation order
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun size_t strxfrm (char *@var{to}, const char *@var{from}, size_t @var{size})
 | 
						|
The function @code{strxfrm} transforms @var{string} using the collation
 | 
						|
transformation determined by the locale currently selected for
 | 
						|
collation, and stores the transformed string in the array @var{to}.  Up
 | 
						|
to @var{size} characters (including a terminating null character) are
 | 
						|
stored.
 | 
						|
 | 
						|
The behavior is undefined if the strings @var{to} and @var{from}
 | 
						|
overlap; see @ref{Copying and Concatenation}.
 | 
						|
 | 
						|
The return value is the length of the entire transformed string.  This
 | 
						|
value is not affected by the value of @var{size}, but if it is greater
 | 
						|
or equal than @var{size}, it means that the transformed string did not
 | 
						|
entirely fit in the array @var{to}.  In this case, only as much of the
 | 
						|
string as actually fits was stored.  To get the whole transformed
 | 
						|
string, call @code{strxfrm} again with a bigger output array.
 | 
						|
 | 
						|
The transformed string may be longer than the original string, and it
 | 
						|
may also be shorter.
 | 
						|
 | 
						|
If @var{size} is zero, no characters are stored in @var{to}.  In this
 | 
						|
case, @code{strxfrm} simply returns the number of characters that would
 | 
						|
be the length of the transformed string.  This is useful for determining
 | 
						|
what size string to allocate.  It does not matter what @var{to} is if
 | 
						|
@var{size} is zero; @var{to} may even be a null pointer.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Here is an example of how you can use @code{strxfrm} when
 | 
						|
you plan to do many comparisons.  It does the same thing as the previous
 | 
						|
example, but much faster, because it has to transform each string only
 | 
						|
once, no matter how many times it is compared with other strings.  Even
 | 
						|
the time needed to allocate and free storage is much less than the time
 | 
						|
we save, when there are many strings.
 | 
						|
 | 
						|
@smallexample
 | 
						|
struct sorter @{ char *input; char *transformed; @};
 | 
						|
 | 
						|
/* @r{This is the comparison function used with @code{qsort}}
 | 
						|
   @r{to sort an array of @code{struct sorter}.} */
 | 
						|
 | 
						|
int
 | 
						|
compare_elements (struct sorter *p1, struct sorter *p2)
 | 
						|
@{
 | 
						|
  return strcmp (p1->transformed, p2->transformed);
 | 
						|
@}
 | 
						|
 | 
						|
/* @r{This is the entry point---the function to sort}
 | 
						|
   @r{strings using the locale's collating sequence.} */
 | 
						|
 | 
						|
void
 | 
						|
sort_strings_fast (char **array, int nstrings)
 | 
						|
@{
 | 
						|
  struct sorter temp_array[nstrings];
 | 
						|
  int i;
 | 
						|
 | 
						|
  /* @r{Set up @code{temp_array}.  Each element contains}
 | 
						|
     @r{one input string and its transformed string.} */
 | 
						|
  for (i = 0; i < nstrings; i++)
 | 
						|
    @{
 | 
						|
      size_t length = strlen (array[i]) * 2;
 | 
						|
      char *transformed;
 | 
						|
      size_t transformed_length;
 | 
						|
 | 
						|
      temp_array[i].input = array[i];
 | 
						|
 | 
						|
      /* @r{First try a buffer perhaps big enough.}  */
 | 
						|
      transformed = (char *) xmalloc (length);
 | 
						|
 | 
						|
      /* @r{Transform @code{array[i]}.}  */
 | 
						|
      transformed_length = strxfrm (transformed, array[i], length);
 | 
						|
 | 
						|
      /* @r{If the buffer was not large enough, resize it}
 | 
						|
         @r{and try again.}  */
 | 
						|
      if (transformed_length >= length)
 | 
						|
        @{
 | 
						|
          /* @r{Allocate the needed space. +1 for terminating}
 | 
						|
             @r{@code{NUL} character.}  */
 | 
						|
          transformed = (char *) xrealloc (transformed,
 | 
						|
                                           transformed_length + 1);
 | 
						|
 | 
						|
          /* @r{The return value is not interesting because we know}
 | 
						|
             @r{how long the transformed string is.}  */
 | 
						|
          (void) strxfrm (transformed, array[i],
 | 
						|
                          transformed_length + 1);
 | 
						|
        @}
 | 
						|
 | 
						|
      temp_array[i].transformed = transformed;
 | 
						|
    @}
 | 
						|
 | 
						|
  /* @r{Sort @code{temp_array} by comparing transformed strings.} */
 | 
						|
  qsort (temp_array, sizeof (struct sorter),
 | 
						|
         nstrings, compare_elements);
 | 
						|
 | 
						|
  /* @r{Put the elements back in the permanent array}
 | 
						|
     @r{in their sorted order.} */
 | 
						|
  for (i = 0; i < nstrings; i++)
 | 
						|
    array[i] = temp_array[i].input;
 | 
						|
 | 
						|
  /* @r{Free the strings we allocated.} */
 | 
						|
  for (i = 0; i < nstrings; i++)
 | 
						|
    free (temp_array[i].transformed);
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@strong{Compatibility Note:}  The string collation functions are a new
 | 
						|
feature of @w{ISO C90}.  Older C dialects have no equivalent feature.
 | 
						|
 | 
						|
@node Search Functions
 | 
						|
@section Search Functions
 | 
						|
 | 
						|
This section describes library functions which perform various kinds
 | 
						|
of searching operations on strings and arrays.  These functions are
 | 
						|
declared in the header file @file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
@cindex search functions (for strings)
 | 
						|
@cindex string search functions
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {void *} memchr (const void *@var{block}, int @var{c}, size_t @var{size})
 | 
						|
This function finds the first occurrence of the byte @var{c} (converted
 | 
						|
to an @code{unsigned char}) in the initial @var{size} bytes of the
 | 
						|
object beginning at @var{block}.  The return value is a pointer to the
 | 
						|
located byte, or a null pointer if no match was found.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void *} memrchr (const void *@var{block}, int @var{c}, size_t @var{size})
 | 
						|
The function @code{memrchr} is like @code{memchr}, except that it searches
 | 
						|
backwards from the end of the block defined by @var{block} and @var{size}
 | 
						|
(instead of forwards from the front).
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strchr (const char *@var{string}, int @var{c})
 | 
						|
The @code{strchr} function finds the first occurrence of the character
 | 
						|
@var{c} (converted to a @code{char}) in the null-terminated string
 | 
						|
beginning at @var{string}.  The return value is a pointer to the located
 | 
						|
character, or a null pointer if no match was found.
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strchr ("hello, world", 'l')
 | 
						|
    @result{} "llo, world"
 | 
						|
strchr ("hello, world", '?')
 | 
						|
    @result{} NULL
 | 
						|
@end smallexample
 | 
						|
 | 
						|
The terminating null character is considered to be part of the string,
 | 
						|
so you can use this function get a pointer to the end of a string by
 | 
						|
specifying a null character as the value of the @var{c} argument.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ???
 | 
						|
@deftypefun {char *} strchrnul (const char *@var{string}, int @var{c})
 | 
						|
@code{strchrnul} is the same as @code{strchr} except that if it does
 | 
						|
not find the character, it returns a pointer to string's terminating 
 | 
						|
null character rather than a null pointer.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
One useful, but unusual, use of the @code{strchr} 
 | 
						|
function is when one wants to have a pointer pointing to the NUL byte
 | 
						|
terminating a string.  This is often written in this way:
 | 
						|
 | 
						|
@smallexample
 | 
						|
  s += strlen (s);
 | 
						|
@end smallexample
 | 
						|
 | 
						|
@noindent
 | 
						|
This is almost optimal but the addition operation duplicated a bit of
 | 
						|
the work already done in the @code{strlen} function.  A better solution
 | 
						|
is this:
 | 
						|
 | 
						|
@smallexample
 | 
						|
  s = strchr (s, '\0');
 | 
						|
@end smallexample
 | 
						|
 | 
						|
There is no restriction on the second parameter of @code{strchr} so it
 | 
						|
could very well also be the NUL character.  Those readers thinking very
 | 
						|
hard about this might now point out that the @code{strchr} function is
 | 
						|
more expensive than the @code{strlen} function since we have two abort
 | 
						|
criteria.  This is right.  But in the GNU C library the implementation of
 | 
						|
@code{strchr} is optimized in a special way so that @code{strchr}
 | 
						|
actually is faster.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strrchr (const char *@var{string}, int @var{c})
 | 
						|
The function @code{strrchr} is like @code{strchr}, except that it searches
 | 
						|
backwards from the end of the string @var{string} (instead of forwards
 | 
						|
from the front).
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strrchr ("hello, world", 'l')
 | 
						|
    @result{} "ld"
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strstr (const char *@var{haystack}, const char *@var{needle})
 | 
						|
This is like @code{strchr}, except that it searches @var{haystack} for a
 | 
						|
substring @var{needle} rather than just a single character.  It
 | 
						|
returns a pointer into the string @var{haystack} that is the first
 | 
						|
character of the substring, or a null pointer if no match was found.  If
 | 
						|
@var{needle} is an empty string, the function returns @var{haystack}.
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strstr ("hello, world", "l")
 | 
						|
    @result{} "llo, world"
 | 
						|
strstr ("hello, world", "wo")
 | 
						|
    @result{} "world"
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ???
 | 
						|
@deftypefun {char *} strcasestr (const char *@var{haystack}, const char *@var{needle})
 | 
						|
This is like @code{strstr}, except that it ignores case in searching for
 | 
						|
the substring.   Like @code{strcasecmp}, it is locale dependent how
 | 
						|
uppercase and lowercase characters are related.
 | 
						|
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strstr ("hello, world", "L")
 | 
						|
    @result{} "llo, world"
 | 
						|
strstr ("hello, World", "wo")
 | 
						|
    @result{} "World"
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void *} memmem (const void *@var{haystack}, size_t @var{haystack-len},@*const void *@var{needle}, size_t @var{needle-len})
 | 
						|
This is like @code{strstr}, but @var{needle} and @var{haystack} are byte
 | 
						|
arrays rather than null-terminated strings.  @var{needle-len} is the
 | 
						|
length of @var{needle} and @var{haystack-len} is the length of
 | 
						|
@var{haystack}.@refill
 | 
						|
 | 
						|
This function is a GNU extension.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun size_t strspn (const char *@var{string}, const char *@var{skipset})
 | 
						|
The @code{strspn} (``string span'') function returns the length of the
 | 
						|
initial substring of @var{string} that consists entirely of characters that
 | 
						|
are members of the set specified by the string @var{skipset}.  The order
 | 
						|
of the characters in @var{skipset} is not important.
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strspn ("hello, world", "abcdefghijklmnopqrstuvwxyz")
 | 
						|
    @result{} 5
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun size_t strcspn (const char *@var{string}, const char *@var{stopset})
 | 
						|
The @code{strcspn} (``string complement span'') function returns the length
 | 
						|
of the initial substring of @var{string} that consists entirely of characters
 | 
						|
that are @emph{not} members of the set specified by the string @var{stopset}.
 | 
						|
(In other words, it returns the offset of the first character in @var{string}
 | 
						|
that is a member of the set @var{stopset}.)
 | 
						|
 | 
						|
For example,
 | 
						|
@smallexample
 | 
						|
strcspn ("hello, world", " \t\n,.;!?")
 | 
						|
    @result{} 5
 | 
						|
@end smallexample
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strpbrk (const char *@var{string}, const char *@var{stopset})
 | 
						|
The @code{strpbrk} (``string pointer break'') function is related to
 | 
						|
@code{strcspn}, except that it returns a pointer to the first character
 | 
						|
in @var{string} that is a member of the set @var{stopset} instead of the
 | 
						|
length of the initial substring.  It returns a null pointer if no such
 | 
						|
character from @var{stopset} is found.
 | 
						|
 | 
						|
@c @group  Invalid outside the example.
 | 
						|
For example,
 | 
						|
 | 
						|
@smallexample
 | 
						|
strpbrk ("hello, world", " \t\n,.;!?")
 | 
						|
    @result{} ", world"
 | 
						|
@end smallexample
 | 
						|
@c @end group
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
 | 
						|
@subsection Compatibility String Search Functions
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun {char *} index (const char *@var{string}, int @var{c})
 | 
						|
@code{index} is another name for @code{strchr}; they are exactly the same.
 | 
						|
New code should always use @code{strchr} since this name is defined in
 | 
						|
@w{ISO C} while @code{index} is a BSD invention which never was available
 | 
						|
on @w{System V} derived systems.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun {char *} rindex (const char *@var{string}, int @var{c})
 | 
						|
@code{rindex} is another name for @code{strrchr}; they are exactly the same.
 | 
						|
New code should always use @code{strrchr} since this name is defined in
 | 
						|
@w{ISO C} while @code{rindex} is a BSD invention which never was available
 | 
						|
on @w{System V} derived systems.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node Finding Tokens in a String
 | 
						|
@section Finding Tokens in a String
 | 
						|
 | 
						|
@cindex tokenizing strings
 | 
						|
@cindex breaking a string into tokens
 | 
						|
@cindex parsing tokens from a string
 | 
						|
It's fairly common for programs to have a need to do some simple kinds
 | 
						|
of lexical analysis and parsing, such as splitting a command string up
 | 
						|
into tokens.  You can do this with the @code{strtok} function, declared
 | 
						|
in the header file @file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment ISO
 | 
						|
@deftypefun {char *} strtok (char *@var{newstring}, const char *@var{delimiters})
 | 
						|
A string can be split into tokens by making a series of calls to the
 | 
						|
function @code{strtok}.
 | 
						|
 | 
						|
The string to be split up is passed as the @var{newstring} argument on
 | 
						|
the first call only.  The @code{strtok} function uses this to set up
 | 
						|
some internal state information.  Subsequent calls to get additional
 | 
						|
tokens from the same string are indicated by passing a null pointer as
 | 
						|
the @var{newstring} argument.  Calling @code{strtok} with another
 | 
						|
non-null @var{newstring} argument reinitializes the state information.
 | 
						|
It is guaranteed that no other library function ever calls @code{strtok}
 | 
						|
behind your back (which would mess up this internal state information).
 | 
						|
 | 
						|
The @var{delimiters} argument is a string that specifies a set of delimiters
 | 
						|
that may surround the token being extracted.  All the initial characters
 | 
						|
that are members of this set are discarded.  The first character that is
 | 
						|
@emph{not} a member of this set of delimiters marks the beginning of the
 | 
						|
next token.  The end of the token is found by looking for the next
 | 
						|
character that is a member of the delimiter set.  This character in the
 | 
						|
original string @var{newstring} is overwritten by a null character, and the
 | 
						|
pointer to the beginning of the token in @var{newstring} is returned.
 | 
						|
 | 
						|
On the next call to @code{strtok}, the searching begins at the next
 | 
						|
character beyond the one that marked the end of the previous token.
 | 
						|
Note that the set of delimiters @var{delimiters} do not have to be the
 | 
						|
same on every call in a series of calls to @code{strtok}.
 | 
						|
 | 
						|
If the end of the string @var{newstring} is reached, or if the remainder of
 | 
						|
string consists only of delimiter characters, @code{strtok} returns
 | 
						|
a null pointer.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@strong{Warning:} Since @code{strtok} alters the string it is parsing,
 | 
						|
you should always copy the string to a temporary buffer before parsing
 | 
						|
it with @code{strtok}.  If you allow @code{strtok} to modify a string
 | 
						|
that came from another part of your program, you are asking for trouble;
 | 
						|
that string might be used for other purposes after @code{strtok} has
 | 
						|
modified it, and it would not have the expected value.
 | 
						|
 | 
						|
The string that you are operating on might even be a constant.  Then
 | 
						|
when @code{strtok} tries to modify it, your program will get a fatal
 | 
						|
signal for writing in read-only memory.  @xref{Program Error Signals}.
 | 
						|
Even if the operation of @code{strtok} would not require a modification
 | 
						|
of the string (e.g., if there is exactly one token) the string can (and
 | 
						|
in the GNU libc case will) be modified.
 | 
						|
 | 
						|
This is a special case of a general principle: if a part of a program
 | 
						|
does not have as its purpose the modification of a certain data
 | 
						|
structure, then it is error-prone to modify the data structure
 | 
						|
temporarily.
 | 
						|
 | 
						|
The function @code{strtok} is not reentrant.  @xref{Nonreentrancy}, for
 | 
						|
a discussion of where and why reentrancy is important.
 | 
						|
 | 
						|
Here is a simple example showing the use of @code{strtok}.
 | 
						|
 | 
						|
@comment Yes, this example has been tested.
 | 
						|
@smallexample
 | 
						|
#include <string.h>
 | 
						|
#include <stddef.h>
 | 
						|
 | 
						|
@dots{}
 | 
						|
 | 
						|
const char string[] = "words separated by spaces -- and, punctuation!";
 | 
						|
const char delimiters[] = " .,;:!-";
 | 
						|
char *token, *cp;
 | 
						|
 | 
						|
@dots{}
 | 
						|
 | 
						|
cp = strdupa (string);                /* Make writable copy.  */
 | 
						|
token = strtok (cp, delimiters);      /* token => "words" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => "separated" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => "by" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => "spaces" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => "and" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => "punctuation" */
 | 
						|
token = strtok (NULL, delimiters);    /* token => NULL */
 | 
						|
@end smallexample
 | 
						|
 | 
						|
The GNU C library contains two more functions for tokenizing a string
 | 
						|
which overcome the limitation of non-reentrancy.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment POSIX
 | 
						|
@deftypefun {char *} strtok_r (char *@var{newstring}, const char *@var{delimiters}, char **@var{save_ptr})
 | 
						|
Just like @code{strtok}, this function splits the string into several
 | 
						|
tokens which can be accessed by successive calls to @code{strtok_r}.
 | 
						|
The difference is that the information about the next token is stored in
 | 
						|
the space pointed to by the third argument, @var{save_ptr}, which is a
 | 
						|
pointer to a string pointer.  Calling @code{strtok_r} with a null
 | 
						|
pointer for @var{newstring} and leaving @var{save_ptr} between the calls
 | 
						|
unchanged does the job without hindering reentrancy.
 | 
						|
 | 
						|
This function is defined in POSIX.1 and can be found on many systems
 | 
						|
which support multi-threading.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment BSD
 | 
						|
@deftypefun {char *} strsep (char **@var{string_ptr}, const char *@var{delimiter})
 | 
						|
This function has a similar functionality as @code{strtok_r} with the
 | 
						|
@var{newstring} argument replaced by the @var{save_ptr} argument.  The
 | 
						|
initialization of the moving pointer has to be done by the user.
 | 
						|
Successive calls to @code{strsep} move the pointer along the tokens
 | 
						|
separated by @var{delimiter}, returning the address of the next token
 | 
						|
and updating @var{string_ptr} to point to the beginning of the next
 | 
						|
token.
 | 
						|
 | 
						|
One difference between @code{strsep} and @code{strtok_r} is that if the
 | 
						|
input string contains more than one character from @var{delimiter} in a
 | 
						|
row @code{strsep} returns an empty string for each pair of characters
 | 
						|
from @var{delimiter}.  This means that a program normally should test
 | 
						|
for @code{strsep} returning an empty string before processing it.
 | 
						|
 | 
						|
This function was introduced in 4.3BSD and therefore is widely available.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
Here is how the above example looks like when @code{strsep} is used.
 | 
						|
 | 
						|
@comment Yes, this example has been tested.
 | 
						|
@smallexample
 | 
						|
#include <string.h>
 | 
						|
#include <stddef.h>
 | 
						|
 | 
						|
@dots{}
 | 
						|
 | 
						|
const char string[] = "words separated by spaces -- and, punctuation!";
 | 
						|
const char delimiters[] = " .,;:!-";
 | 
						|
char *running;
 | 
						|
char *token;
 | 
						|
 | 
						|
@dots{}
 | 
						|
 | 
						|
running = strdupa (string);
 | 
						|
token = strsep (&running, delimiters);    /* token => "words" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "separated" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "by" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "spaces" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "and" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "punctuation" */
 | 
						|
token = strsep (&running, delimiters);    /* token => "" */
 | 
						|
token = strsep (&running, delimiters);    /* token => NULL */
 | 
						|
@end smallexample
 | 
						|
 | 
						|
 | 
						|
@node strfry
 | 
						|
@section strfry
 | 
						|
 | 
						|
The function below addresses the perennial programming quandary: ``How do
 | 
						|
I take good data in string form and painlessly turn it into garbage?''
 | 
						|
This is actually a fairly simple task for C programmers who do not use
 | 
						|
the GNU C library string functions, but for programs based on the GNU C
 | 
						|
library, the @code{strfry} function is the preferred method for
 | 
						|
destroying string data.
 | 
						|
 | 
						|
The prototype for this function is in @file{string.h}.
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} strfry (char *@var{string}) 
 | 
						|
 | 
						|
@code{strfry} creates a pseudorandom anagram of a string, replacing the
 | 
						|
input with the anagram in place.  For each position in the string,
 | 
						|
@code{strfry} swaps it with a position in the string selected at random
 | 
						|
(from a uniform distribution).  The two positions may be the same.
 | 
						|
 | 
						|
The return value of @code{strfry} is always @var{string}.
 | 
						|
 | 
						|
@strong{Portability Note:}  This function is unique to the GNU C library.
 | 
						|
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
 | 
						|
@node Trivial Encryption
 | 
						|
@section Trivial Encryption
 | 
						|
@cindex encryption
 | 
						|
 | 
						|
 | 
						|
The @code{memfrob} function converts an array of data to something
 | 
						|
unrecognizable and back again.  It is not encryption in its usual sense
 | 
						|
since it is easy for someone to convert the encrypted data back to clear
 | 
						|
text.  The transformation is analogous to Usenet's ``Rot13'' encryption
 | 
						|
method for obscuring offensive jokes from sensitive eyes and such.
 | 
						|
Unlike Rot13, @code{memfrob} works on arbitrary binary data, not just
 | 
						|
text.
 | 
						|
@cindex Rot13
 | 
						|
 | 
						|
For true encryption, @xref{Cryptographic Functions}.
 | 
						|
 | 
						|
This function is declared in @file{string.h}.
 | 
						|
@pindex string.h
 | 
						|
 | 
						|
@comment string.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void *} memfrob (void *@var{mem}, size_t @var{length})
 | 
						|
 | 
						|
@code{memfrob} transforms (frobnicates) each byte of the data structure
 | 
						|
at @var{mem}, which is @var{length} bytes long, by bitwise exclusive
 | 
						|
oring it with binary 00101010.  It does the transformation in place and
 | 
						|
its return value is always @var{mem}.
 | 
						|
 | 
						|
Note that @code{memfrob} a second time on the same data structure
 | 
						|
returns it to its original state.
 | 
						|
 | 
						|
This is a good function for hiding information from someone who doesn't
 | 
						|
want to see it or doesn't want to see it very much.  To really prevent
 | 
						|
people from retrieving the information, use stronger encryption such as
 | 
						|
that described in @xref{Cryptographic Functions}.
 | 
						|
 | 
						|
@strong{Portability Note:}  This function is unique to the GNU C library.
 | 
						|
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node Encode Binary Data
 | 
						|
@section Encode Binary Data
 | 
						|
 | 
						|
To store or transfer binary data in environments which only support text
 | 
						|
one has to encode the binary data by mapping the input bytes to
 | 
						|
characters in the range allowed for storing or transfering.  SVID
 | 
						|
systems (and nowadays XPG compliant systems) provide minimal support for
 | 
						|
this task.
 | 
						|
 | 
						|
@comment stdlib.h
 | 
						|
@comment XPG
 | 
						|
@deftypefun {char *} l64a (long int @var{n})
 | 
						|
This function encodes a 32-bit input value using characters from the
 | 
						|
basic character set.  It returns a pointer to a 6 character buffer which
 | 
						|
contains an encoded version of @var{n}.  To encode a series of bytes the
 | 
						|
user must copy the returned string to a destination buffer.  It returns
 | 
						|
the empty string if @var{n} is zero, which is somewhat bizarre but
 | 
						|
mandated by the standard.@*
 | 
						|
@strong{Warning:} Since a static buffer is used this function should not
 | 
						|
be used in multi-threaded programs.  There is no thread-safe alternative
 | 
						|
to this function in the C library.@*
 | 
						|
@strong{Compatibility Note:} The XPG standard states that the return
 | 
						|
value of @code{l64a} is undefined if @var{n} is negative.  In the GNU
 | 
						|
implementation, @code{l64a} treats its argument as unsigned, so it will
 | 
						|
return a sensible encoding for any nonzero @var{n}; however, portable
 | 
						|
programs should not rely on this.
 | 
						|
 | 
						|
To encode a large buffer @code{l64a} must be called in a loop, once for
 | 
						|
each 32-bit word of the buffer.  For example, one could do something
 | 
						|
like this:
 | 
						|
 | 
						|
@smallexample
 | 
						|
char *
 | 
						|
encode (const void *buf, size_t len)
 | 
						|
@{
 | 
						|
  /* @r{We know in advance how long the buffer has to be.} */
 | 
						|
  unsigned char *in = (unsigned char *) buf;
 | 
						|
  char *out = malloc (6 + ((len + 3) / 4) * 6 + 1);
 | 
						|
  char *cp = out;
 | 
						|
 | 
						|
  /* @r{Encode the length.} */
 | 
						|
  /* @r{Using `htonl' is necessary so that the data can be}
 | 
						|
     @r{decoded even on machines with different byte order.} */
 | 
						|
 | 
						|
  cp = mempcpy (cp, l64a (htonl (len)), 6);
 | 
						|
 | 
						|
  while (len > 3)
 | 
						|
    @{
 | 
						|
      unsigned long int n = *in++;
 | 
						|
      n = (n << 8) | *in++;
 | 
						|
      n = (n << 8) | *in++;
 | 
						|
      n = (n << 8) | *in++;
 | 
						|
      len -= 4;
 | 
						|
      if (n)
 | 
						|
        cp = mempcpy (cp, l64a (htonl (n)), 6);
 | 
						|
      else
 | 
						|
            /* @r{`l64a' returns the empty string for n==0, so we }
 | 
						|
               @r{must generate its encoding (}"......"@r{) by hand.} */
 | 
						|
        cp = stpcpy (cp, "......");
 | 
						|
    @}
 | 
						|
  if (len > 0)
 | 
						|
    @{
 | 
						|
      unsigned long int n = *in++;
 | 
						|
      if (--len > 0)
 | 
						|
        @{
 | 
						|
          n = (n << 8) | *in++;
 | 
						|
          if (--len > 0)
 | 
						|
            n = (n << 8) | *in;
 | 
						|
        @}
 | 
						|
      memcpy (cp, l64a (htonl (n)), 6);
 | 
						|
      cp += 6;
 | 
						|
    @}
 | 
						|
  *cp = '\0';
 | 
						|
  return out;
 | 
						|
@}
 | 
						|
@end smallexample
 | 
						|
 | 
						|
It is strange that the library does not provide the complete
 | 
						|
functionality needed but so be it.
 | 
						|
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
To decode data produced with @code{l64a} the following function should be
 | 
						|
used.
 | 
						|
 | 
						|
@comment stdlib.h
 | 
						|
@comment XPG
 | 
						|
@deftypefun {long int} a64l (const char *@var{string})
 | 
						|
The parameter @var{string} should contain a string which was produced by
 | 
						|
a call to @code{l64a}.  The function processes at least 6 characters of
 | 
						|
this string, and decodes the characters it finds according to the table
 | 
						|
below.  It stops decoding when it finds a character not in the table,
 | 
						|
rather like @code{atoi}; if you have a buffer which has been broken into
 | 
						|
lines, you must be careful to skip over the end-of-line characters.
 | 
						|
 | 
						|
The decoded number is returned as a @code{long int} value.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
The @code{l64a} and @code{a64l} functions use a base 64 encoding, in
 | 
						|
which each character of an encoded string represents six bits of an
 | 
						|
input word.  These symbols are used for the base 64 digits:
 | 
						|
 | 
						|
@multitable {xxxxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx} {xxx}
 | 
						|
@item              @tab 0 @tab 1 @tab 2 @tab 3 @tab 4 @tab 5 @tab 6 @tab 7
 | 
						|
@item       0      @tab @code{.} @tab @code{/} @tab @code{0} @tab @code{1}
 | 
						|
                   @tab @code{2} @tab @code{3} @tab @code{4} @tab @code{5}
 | 
						|
@item       8      @tab @code{6} @tab @code{7} @tab @code{8} @tab @code{9}
 | 
						|
                   @tab @code{A} @tab @code{B} @tab @code{C} @tab @code{D}
 | 
						|
@item       16     @tab @code{E} @tab @code{F} @tab @code{G} @tab @code{H}
 | 
						|
                   @tab @code{I} @tab @code{J} @tab @code{K} @tab @code{L}
 | 
						|
@item       24     @tab @code{M} @tab @code{N} @tab @code{O} @tab @code{P}
 | 
						|
                   @tab @code{Q} @tab @code{R} @tab @code{S} @tab @code{T}
 | 
						|
@item       32     @tab @code{U} @tab @code{V} @tab @code{W} @tab @code{X}
 | 
						|
                   @tab @code{Y} @tab @code{Z} @tab @code{a} @tab @code{b}
 | 
						|
@item       40     @tab @code{c} @tab @code{d} @tab @code{e} @tab @code{f}
 | 
						|
                   @tab @code{g} @tab @code{h} @tab @code{i} @tab @code{j}
 | 
						|
@item       48     @tab @code{k} @tab @code{l} @tab @code{m} @tab @code{n}
 | 
						|
                   @tab @code{o} @tab @code{p} @tab @code{q} @tab @code{r}
 | 
						|
@item       56     @tab @code{s} @tab @code{t} @tab @code{u} @tab @code{v}
 | 
						|
                   @tab @code{w} @tab @code{x} @tab @code{y} @tab @code{z}
 | 
						|
@end multitable
 | 
						|
 | 
						|
This encoding scheme is not standard.  There are some other encoding
 | 
						|
methods which are much more widely used (UU encoding, MIME encoding).
 | 
						|
Generally, it is better to use one of these encodings.
 | 
						|
 | 
						|
@node Argz and Envz Vectors
 | 
						|
@section Argz and Envz Vectors
 | 
						|
 | 
						|
@cindex argz vectors (string vectors)
 | 
						|
@cindex string vectors, null-character separated
 | 
						|
@cindex argument vectors, null-character separated
 | 
						|
@dfn{argz vectors} are vectors of strings in a contiguous block of
 | 
						|
memory, each element separated from its neighbors by null-characters
 | 
						|
(@code{'\0'}).
 | 
						|
 | 
						|
@cindex envz vectors (environment vectors)
 | 
						|
@cindex environment vectors, null-character separated
 | 
						|
@dfn{Envz vectors} are an extension of argz vectors where each element is a
 | 
						|
name-value pair, separated by a @code{'='} character (as in a Unix
 | 
						|
environment).
 | 
						|
 | 
						|
@menu
 | 
						|
* Argz Functions::              Operations on argz vectors.
 | 
						|
* Envz Functions::              Additional operations on environment vectors.
 | 
						|
@end menu
 | 
						|
 | 
						|
@node Argz Functions, Envz Functions, , Argz and Envz Vectors
 | 
						|
@subsection Argz Functions
 | 
						|
 | 
						|
Each argz vector is represented by a pointer to the first element, of
 | 
						|
type @code{char *}, and a size, of type @code{size_t}, both of which can
 | 
						|
be initialized to @code{0} to represent an empty argz vector.  All argz
 | 
						|
functions accept either a pointer and a size argument, or pointers to
 | 
						|
them, if they will be modified.
 | 
						|
 | 
						|
The argz functions use @code{malloc}/@code{realloc} to allocate/grow
 | 
						|
argz vectors, and so any argz vector creating using these functions may
 | 
						|
be freed by using @code{free}; conversely, any argz function that may
 | 
						|
grow a string expects that string to have been allocated using
 | 
						|
@code{malloc} (those argz functions that only examine their arguments or
 | 
						|
modify them in place will work on any sort of memory).
 | 
						|
@xref{Unconstrained Allocation}.
 | 
						|
 | 
						|
All argz functions that do memory allocation have a return type of
 | 
						|
@code{error_t}, and return @code{0} for success, and @code{ENOMEM} if an
 | 
						|
allocation error occurs.
 | 
						|
 | 
						|
@pindex argz.h
 | 
						|
These functions are declared in the standard include file @file{argz.h}.
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_create (char *const @var{argv}[], char **@var{argz}, size_t *@var{argz_len})
 | 
						|
The @code{argz_create} function converts the Unix-style argument vector
 | 
						|
@var{argv} (a vector of pointers to normal C strings, terminated by
 | 
						|
@code{(char *)0}; @pxref{Program Arguments}) into an argz vector with
 | 
						|
the same elements, which is returned in @var{argz} and @var{argz_len}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_create_sep (const char *@var{string}, int @var{sep}, char **@var{argz}, size_t *@var{argz_len})
 | 
						|
The @code{argz_create_sep} function converts the null-terminated string
 | 
						|
@var{string} into an argz vector (returned in @var{argz} and
 | 
						|
@var{argz_len}) by splitting it into elements at every occurrence of the
 | 
						|
character @var{sep}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {size_t} argz_count (const char *@var{argz}, size_t @var{arg_len})
 | 
						|
Returns the number of elements in the argz vector @var{argz} and
 | 
						|
@var{argz_len}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void} argz_extract (char *@var{argz}, size_t @var{argz_len}, char **@var{argv})
 | 
						|
The @code{argz_extract} function converts the argz vector @var{argz} and
 | 
						|
@var{argz_len} into a Unix-style argument vector stored in @var{argv},
 | 
						|
by putting pointers to every element in @var{argz} into successive
 | 
						|
positions in @var{argv}, followed by a terminator of @code{0}.
 | 
						|
@var{Argv} must be pre-allocated with enough space to hold all the
 | 
						|
elements in @var{argz} plus the terminating @code{(char *)0}
 | 
						|
(@code{(argz_count (@var{argz}, @var{argz_len}) + 1) * sizeof (char *)}
 | 
						|
bytes should be enough).  Note that the string pointers stored into
 | 
						|
@var{argv} point into @var{argz}---they are not copies---and so
 | 
						|
@var{argz} must be copied if it will be changed while @var{argv} is
 | 
						|
still active.  This function is useful for passing the elements in
 | 
						|
@var{argz} to an exec function (@pxref{Executing a File}).
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void} argz_stringify (char *@var{argz}, size_t @var{len}, int @var{sep})
 | 
						|
The @code{argz_stringify} converts @var{argz} into a normal string with
 | 
						|
the elements separated by the character @var{sep}, by replacing each
 | 
						|
@code{'\0'} inside @var{argz} (except the last one, which terminates the
 | 
						|
string) with @var{sep}.  This is handy for printing @var{argz} in a
 | 
						|
readable manner.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_add (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str})
 | 
						|
The @code{argz_add} function adds the string @var{str} to the end of the
 | 
						|
argz vector @code{*@var{argz}}, and updates @code{*@var{argz}} and
 | 
						|
@code{*@var{argz_len}} accordingly.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_add_sep (char **@var{argz}, size_t *@var{argz_len}, const char *@var{str}, int @var{delim})
 | 
						|
The @code{argz_add_sep} function is similar to @code{argz_add}, but
 | 
						|
@var{str} is split into separate elements in the result at occurrences of
 | 
						|
the character @var{delim}.  This is useful, for instance, for
 | 
						|
adding the components of a Unix search path to an argz vector, by using
 | 
						|
a value of @code{':'} for @var{delim}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_append (char **@var{argz}, size_t *@var{argz_len}, const char *@var{buf}, size_t @var{buf_len})
 | 
						|
The @code{argz_append} function appends @var{buf_len} bytes starting at
 | 
						|
@var{buf} to the argz vector @code{*@var{argz}}, reallocating
 | 
						|
@code{*@var{argz}} to accommodate it, and adding @var{buf_len} to
 | 
						|
@code{*@var{argz_len}}.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_delete (char **@var{argz}, size_t *@var{argz_len}, char *@var{entry})
 | 
						|
If @var{entry} points to the beginning of one of the elements in the
 | 
						|
argz vector @code{*@var{argz}}, the @code{argz_delete} function will
 | 
						|
remove this entry and reallocate @code{*@var{argz}}, modifying
 | 
						|
@code{*@var{argz}} and @code{*@var{argz_len}} accordingly.  Note that as
 | 
						|
destructive argz functions usually reallocate their argz argument,
 | 
						|
pointers into argz vectors such as @var{entry} will then become invalid.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} argz_insert (char **@var{argz}, size_t *@var{argz_len}, char *@var{before}, const char *@var{entry})
 | 
						|
The @code{argz_insert} function inserts the string @var{entry} into the
 | 
						|
argz vector @code{*@var{argz}} at a point just before the existing
 | 
						|
element pointed to by @var{before}, reallocating @code{*@var{argz}} and
 | 
						|
updating @code{*@var{argz}} and @code{*@var{argz_len}}.  If @var{before}
 | 
						|
is @code{0}, @var{entry} is added to the end instead (as if by
 | 
						|
@code{argz_add}).  Since the first element is in fact the same as
 | 
						|
@code{*@var{argz}}, passing in @code{*@var{argz}} as the value of
 | 
						|
@var{before} will result in @var{entry} being inserted at the beginning.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} argz_next (char *@var{argz}, size_t @var{argz_len}, const char *@var{entry})
 | 
						|
The @code{argz_next} function provides a convenient way of iterating
 | 
						|
over the elements in the argz vector @var{argz}.  It returns a pointer
 | 
						|
to the next element in @var{argz} after the element @var{entry}, or
 | 
						|
@code{0} if there are no elements following @var{entry}.  If @var{entry}
 | 
						|
is @code{0}, the first element of @var{argz} is returned.
 | 
						|
 | 
						|
This behavior suggests two styles of iteration:
 | 
						|
 | 
						|
@smallexample
 | 
						|
    char *entry = 0;
 | 
						|
    while ((entry = argz_next (@var{argz}, @var{argz_len}, entry)))
 | 
						|
      @var{action};
 | 
						|
@end smallexample
 | 
						|
 | 
						|
(the double parentheses are necessary to make some C compilers shut up
 | 
						|
about what they consider a questionable @code{while}-test) and:
 | 
						|
 | 
						|
@smallexample
 | 
						|
    char *entry;
 | 
						|
    for (entry = @var{argz};
 | 
						|
         entry;
 | 
						|
         entry = argz_next (@var{argz}, @var{argz_len}, entry))
 | 
						|
      @var{action};
 | 
						|
@end smallexample
 | 
						|
 | 
						|
Note that the latter depends on @var{argz} having a value of @code{0} if
 | 
						|
it is empty (rather than a pointer to an empty block of memory); this
 | 
						|
invariant is maintained for argz vectors created by the functions here.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment argz.h
 | 
						|
@comment GNU
 | 
						|
@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}})
 | 
						|
Replace any occurrences of the string @var{str} in @var{argz} with
 | 
						|
@var{with}, reallocating @var{argz} as necessary.  If
 | 
						|
@var{replace_count} is non-zero, @code{*@var{replace_count}} will be
 | 
						|
incremented by number of replacements performed.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@node Envz Functions, , Argz Functions, Argz and Envz Vectors
 | 
						|
@subsection Envz Functions
 | 
						|
 | 
						|
Envz vectors are just argz vectors with additional constraints on the form
 | 
						|
of each element; as such, argz functions can also be used on them, where it
 | 
						|
makes sense.
 | 
						|
 | 
						|
Each element in an envz vector is a name-value pair, separated by a @code{'='}
 | 
						|
character; if multiple @code{'='} characters are present in an element, those
 | 
						|
after the first are considered part of the value, and treated like all other
 | 
						|
non-@code{'\0'} characters.
 | 
						|
 | 
						|
If @emph{no} @code{'='} characters are present in an element, that element is
 | 
						|
considered the name of a ``null'' entry, as distinct from an entry with an
 | 
						|
empty value: @code{envz_get} will return @code{0} if given the name of null
 | 
						|
entry, whereas an entry with an empty value would result in a value of
 | 
						|
@code{""}; @code{envz_entry} will still find such entries, however.  Null
 | 
						|
entries can be removed with @code{envz_strip} function.
 | 
						|
 | 
						|
As with argz functions, envz functions that may allocate memory (and thus
 | 
						|
fail) have a return type of @code{error_t}, and return either @code{0} or
 | 
						|
@code{ENOMEM}.
 | 
						|
 | 
						|
@pindex envz.h
 | 
						|
These functions are declared in the standard include file @file{envz.h}.
 | 
						|
 | 
						|
@comment envz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} envz_entry (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
 | 
						|
The @code{envz_entry} function finds the entry in @var{envz} with the name
 | 
						|
@var{name}, and returns a pointer to the whole entry---that is, the argz
 | 
						|
element which begins with @var{name} followed by a @code{'='} character.  If
 | 
						|
there is no entry with that name, @code{0} is returned.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment envz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {char *} envz_get (const char *@var{envz}, size_t @var{envz_len}, const char *@var{name})
 | 
						|
The @code{envz_get} function finds the entry in @var{envz} with the name
 | 
						|
@var{name} (like @code{envz_entry}), and returns a pointer to the value
 | 
						|
portion of that entry (following the @code{'='}).  If there is no entry with
 | 
						|
that name (or only a null entry), @code{0} is returned.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment envz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {error_t} envz_add (char **@var{envz}, size_t *@var{envz_len}, const char *@var{name}, const char *@var{value})
 | 
						|
The @code{envz_add} function adds an entry to @code{*@var{envz}}
 | 
						|
(updating @code{*@var{envz}} and @code{*@var{envz_len}}) with the name
 | 
						|
@var{name}, and value @var{value}.  If an entry with the same name
 | 
						|
already exists in @var{envz}, it is removed first.  If @var{value} is
 | 
						|
@code{0}, then the new entry will the special null type of entry
 | 
						|
(mentioned above).
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment envz.h
 | 
						|
@comment GNU
 | 
						|
@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})
 | 
						|
The @code{envz_merge} function adds each entry in @var{envz2} to @var{envz},
 | 
						|
as if with @code{envz_add}, updating @code{*@var{envz}} and
 | 
						|
@code{*@var{envz_len}}.  If @var{override} is true, then values in @var{envz2}
 | 
						|
will supersede those with the same name in @var{envz}, otherwise not.
 | 
						|
 | 
						|
Null entries are treated just like other entries in this respect, so a null
 | 
						|
entry in @var{envz} can prevent an entry of the same name in @var{envz2} from
 | 
						|
being added to @var{envz}, if @var{override} is false.
 | 
						|
@end deftypefun
 | 
						|
 | 
						|
@comment envz.h
 | 
						|
@comment GNU
 | 
						|
@deftypefun {void} envz_strip (char **@var{envz}, size_t *@var{envz_len})
 | 
						|
The @code{envz_strip} function removes any null entries from @var{envz},
 | 
						|
updating @code{*@var{envz}} and @code{*@var{envz_len}}.
 | 
						|
@end deftypefun
 |