Definitions
A string is defined as a contiguous sequence ofchar
, which is exactly 8 bits on all modern machines. C90 defines ''wide strings'' which use a code unit of type wchar_t
, which is 16 or 32 bits on modern machines. This was intended for Unicode but it is increasingly common to use UTF-8 in normal strings for Unicode instead.
Strings are passed to functions by passing a pointer to the first code unit. Since char*
and wchar_t*
are different types, the functions that process wide strings are different than the ones processing normal strings and have different names.
"text"
in the C source code) are converted to arrays during compilation. The result is an array of code units containing all the characters plus a trailing zero code unit. In C90 L"text"
produces a wide string. A string literal can contain the zero code unit (one way is to put \0
into the source), but this will cause the string to end at that point. The rest of the literal will be placed in memory (with another zero code unit added to the end) but it is impossible to know those code units were translated from the string literal, therefore such source code is ''not'' a string literal.
Character encodings
Each string ends at the first occurrence of the zero code unit of the appropriate kind (char
or wchar_t
). Consequently, a byte string () can contain non- NUL characters in wchar_t
. In most implementations, wchar_t
is at least 16 bits, and so all 16-bit encodings, such as UCS-2, can be stored. If wchar_t
is 32-bits, then 32-bit encodings, such as wchar_t
, not in "characters", which can be confusing to beginning programmers. UTF-8 and wchar_t
is 16 bits. Truncating strings with variable-width characters using functions like strncpy
can produce invalid sequences at the end of the string. This can be unsafe if the truncated parts are interpreted by code that assumes the input is valid.
Support for Unicode literals such as (UTF-8) or (UTF-16 or UTF-32, depends on ) is implementation defined, and may require that the source code be in the same encoding, especially for where compilers might just copy whatever is between the quotes. Some compilers or editors will require entering all non-ASCII characters as \xNN
sequences for each byte of UTF-8, and/or \uNNNN
for each word of UTF-16. Since C11 (and C++11), a new literal syntax is available that guarantees UTF-8 for a bytestring literal.
Overview of functions
Most of the functions that operate on C strings are declared in thestring.h
header (cstring
in C++), while functions that operate on C wide strings are declared in the wchar.h
header (cwchar
in C++). These headers also contain declarations of functions used for handling memory buffers; the name is thus something of a misnomer.
Functions declared in string.h
are extremely popular since, as a part of the const
string pointer and returning a non-const
pointer within the string. To correct this, some have been separated into two overloaded functions in the C++ version of the standard library.
In historical documentation the term "character" was often used instead of "byte" for C strings, which leads many to believe that these functions somehow do not work for UTF-8. In fact all lengths are defined as being in bytes and this is true in all implementations, and these functions work as well with UTF-8 as with single-byte encodings. The BSD documentation has been fixed to make this clear, but POSIX, Linux, and Windows documentation still uses "character" in many places where "byte" or "wchar_t" is the correct term.
Functions for handling memory buffers can process sequences of bytes that include null-byte as part of the data. Names of these functions typically start with mem
, as opposite to the str
prefix.
Constants and types
Functions
Multibyte functions
These functions all take a pointer to a object that the caller must maintain. This was originally intended to track shift states in the encodings, but modern ones such as UTF-8 do not need this. However these functions were designed on the assumption that the encoding is not a variable-width encoding and thus are designed to deal with exactly one at a time, passing it by value rather than using a string pointer. As UTF-16 is a variable-width encoding, the has been reused to keep track of surrogate pairs in the wide encoding, though the caller must still detect and call twice for a single character.Numeric conversions
The C standard library contains several functions for numeric conversions. The functions that deal with byte strings are defined in the header ( header in C++). The functions that deal with wide strings are defined in the header ( header in C++). The functions are not const-correct, since they accept a string pointer and return a non- pointer within the string. Also, since the Normative Amendment 1 (C95), functions are considered subsumed by functions, for which reason neither C95 nor any later standard provides wide-character versions of these functions. The argument against is that they do not differentiate between an error and a .Popular extensions
Replacements
Despite the well-established need to replacestrcat
and strcpy
with functions that do not allow buffer overflows, no accepted standard has arisen. This is partly due to the mistaken belief by many C programmers that strncat
and strncpy
have the desired behavior; however, neither function was designed for this (they were intended to manipulate null-padded fixed-size string buffers, a data format less commonly used in modern software), and the behavior and arguments are non-intuitive and often written incorrectly even by expert programmers.
The most popular replacement are the strlcat
and strlcpy
functions, which appeared in OpenBSD 2.4 in December, 1998. These functions always write one NUL to the destination buffer, truncating the result if necessary, and return the size of buffer that would be needed, which allows detection of the truncation and provides a size for creating a new buffer that will not truncate. They have been criticized on the basis of allegedly being inefficient, encouraging the use of C strings (instead of some superior alternative form of string),libc-alpha mailing listmemcpy
or memmove
are used, as they may be more efficient than strcpy
as they do not repeatedly check for NUL (this is less true on modern processors). Since they need a buffer length as a parameter, correct setting of this parameter can avoid buffer overflows.
As part of its 2004 strcpy_s
and strcat_s
(along with many others). These functions were standardized with some minor changes as part of the optional C11 (Annex K) proposed by ISO/IEC WDTR 24731. These functions perform various checks including whether the string is too long to fit in the buffer. If the checks fail, a user-specified "runtime-constraint handler" function is called, which usually aborts the program. Some functions perform destructive operations before calling the runtime-constraint handler; for example, strcat_s
sets the destination to the empty string, which can make it difficult to recover from error conditions or debug them. These functions attracted considerable criticism because initially they were implemented only on Windows and at the same time warning messages started to be produced by Microsoft Visual C++ suggesting the programmers to use these functions instead of standard ones. This has been speculated by some to be an attempt by Microsoft to lock developers into its platform. Although open-source implementations of these functions are available, these functions are not present in common Unix C libraries. Experience with these functions has shown significant problems with their adoption and errors in usage, so the removal of Annex K is proposed for the next revision of the C standard. Usage of has also been suggested as a way to avoid unwanted compiler optimizations.
See also
* source code syntax, including backslash escape sequences *Notes
References
External links