mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-10 15:20:10 +00:00
e52236e536
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
|