Misplaced Pages

#944055

35-398: (Redirected from C-string ) C string may refer to: C string handling , in the C programming language C-string (clothing) , a specific type of thong, or a brand of women shorts C string (music) , one of the strings on various instruments, for example the lowest string on the viola and cello See also [ edit ] CString ,

70-472: A 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. These functions all need a mbstate_t object, originally in static memory (making the functions not be thread-safe) and in later additions the caller must maintain. This was originally intended to track shift states in

105-602: A C string representation in the Microsoft Foundation Class Library (MFC) Topics referred to by the same term [REDACTED] This disambiguation page lists articles associated with the title C string . If an internal link led you here, you may wish to change the link to point directly to the intended article. Retrieved from " https://en.wikipedia.org/w/index.php?title=C_string&oldid=1184643326 " Category : Disambiguation pages Hidden categories: Short description

140-539: A bytestring literal, as in char foo [ 512 ] = u8 "φωωβαρ" ; . Since C++20 and C23 , a char8_t type was added that is meant to store UTF-8 characters and the types of u8 prefixed character and string literals were changed to char8_t and char8_t[] respectively. 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

175-454: A contiguous sequence of code units terminated by the first zero code unit (often called the NUL code unit). This means a string cannot contain the zero code unit, as the first one seen marks the end of the string. The length of a string is the number of code units before the zero code unit. The memory occupied by a string is always one more code unit than the length, as space is needed to store

210-515: 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

245-451: A null character by holding down Ctrl and pressing @ (on US layouts just Ctrl + 2 will often work, there being no need for ⇧ Shift to get the @ sign). The Hexadecimal notation for null is 00 . Decoding the Base64 string AA== also yields the null character. In documentation, the null character is sometimes represented as a single- em -width symbol containing

280-400: A null character does not always mean the resulting string will be correctly interpreted, as many programs will consider the null to be the end of the string. Thus the ability to type it (in case of unchecked user input ) creates a vulnerability known as null byte injection and can lead to security exploits. In caret notation the null character is ^@ . On some keyboards, one can enter

315-489: A number of other C libraries including ones for OpenBSD, FreeBSD , NetBSD , Solaris , OS X , and QNX , as well as in alternative C libraries for Linux, such as libbsd , introduced in 2008, and musl , introduced in 2011, and the source code added directly to other projects such as SDL , GLib , ffmpeg , rsync , and even internally in the Linux kernel . This did change in 2024, the glibc FAQ notes that as of glibc 2.38,

350-437: A parameter, correct setting of this parameter can avoid buffer overflows. As part of its 2004 Security Development Lifecycle , Microsoft introduced a family of "secure" functions including 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

385-426: A part of the C standard library , they are guaranteed to work on any platform which supports C. However, some security issues exist with these functions, such as potential buffer overflows when not used carefully and properly, causing the programmers to prefer safer and possibly less portable variants, out of which some popular ones are listed below. Some of these functions also violate const-correctness by accepting

SECTION 10

#1732798052945

420-435: 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. String literals ( "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

455-405: A single octal digit 0; as a consequence, \0 must not be followed by any of the digits 0 through 7 ; otherwise it is interpreted as the start of a longer octal escape sequence. Other escape sequences that are found in use in various languages are \000 , \x00 , \z , or \u0000 . A null character can be placed in a URL with the percent code %00 . The ability to represent

490-419: 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. Each string ends at

525-402: Is different from Wikidata All article disambiguation pages All disambiguation pages C string handling The C programming language has a set of functions implementing operations on strings (character strings and byte strings) in its standard library . Various operations, such as copying, concatenation , tokenization and searching are supported. For character strings,

560-430: Is implementation defined, and may require that the source code be in the same encoding, especially for char 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 prefix u8 is available that guarantees UTF-8 for

595-501: Is often used in C wide strings when 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 char foo [ 512 ] = "φωωβαρ" ; (UTF-8) or wchar_t foo [ 512 ] = L "φωωβαρ" ; (UTF-16 or UTF-32, depends on wchar_t )

630-469: Is that they do not differentiate between an error and a 0 . Despite the well-established need to replace strcat 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,

665-477: 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

700-421: The mb encodings, but modern ones such as UTF-8 do not need this. However these functions were designed on the assumption that the wc encoding is not a variable-width encoding and thus are designed to deal with exactly one wchar_t at a time, passing it by value rather than using a string pointer. As UTF-16 is a variable-width encoding, the mbstate_t has been reused to keep track of surrogate pairs in

735-483: The str prefix. Most of the functions that operate on C strings are declared in the string.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

SECTION 20

#1732798052945

770-696: The wchar.h header ( cwchar header in C++). The functions strchr , bsearch , strpbrk , strrchr , strstr , memchr and their wide counterparts are not const-correct , since they accept a const string pointer and return a non- const pointer within the string. This has been fixed in C23 . Also, since the Normative Amendment 1 (C95), atoxx functions are considered subsumed by strtoxxx functions, for which reason neither C95 nor any later standard provides wide-character versions of these functions. The argument against atoxx

805-442: The null-terminated string article). In source code , the null character is often represented as the escape sequence \0 in string literals (for example, "abc\0def" ) or in character constants ( '\0' ); the latter may also be written instead simply as 0 (without quotes nor slash). In many languages ( such as C , which introduced this notation), this is not a separate escape sequence, but an octal escape sequence with

840-500: The code has been committed and thereby added. These functions were standardized as part of POSIX.1-2024, the Austin Group Defect Tracker ID 986 tracked some discussion about such plans for POSIX. Sometimes memcpy 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

875-441: The end of each printed line to allow time for the mechanism to return to the first printing position on the next line. On punched tape , the character is represented with no holes at all, so a new unpunched tape is initially filled with null characters, and often text could be inserted at a reserved space of null characters by punching the new characters into the tape over the nulls. Today the character has much more significance in

910-454: The first occurrence of the zero code unit of the appropriate kind ( char or wchar_t ). Consequently, a byte string ( char* ) can contain non- NUL characters in ASCII or any ASCII extension , but not characters in encodings such as UTF-16 (even though a 16-bit code unit might be nonzero, its high or low byte might be zero). The encodings that can be stored in wide strings are defined by

945-535: The letters "NUL". In Unicode , there is a character for this: U+2400 ␀ SYMBOL FOR NULL . In all modern character sets, the null character has a code point value of zero. In most encodings, this is translated to a single code unit with a zero value. For instance, in UTF-8 it is a single zero byte. However, in Modified UTF-8 the null character is encoded as two bytes: 0xC0,0x80 . This allows

980-444: The programming language C and its derivatives and in many data formats, where it serves as a reserved character used to signify the end of a string , often called a null-terminated string . This allows the string to be any length with only the overhead of one byte; the alternative of storing a count requires either a string length limit of 255 or an overhead of more than one byte (there are other advantages/disadvantages described in

1015-494: The removal of Annex K is proposed for the next revision of the C standard. Usage of memset_s has been suggested as a way to avoid unwanted compiler optimizations. Null character The original meaning of this character was like NOP —when sent to a printer or a terminal , it has no effect (some terminals, however, incorrectly display it as space ). When electromechanical teleprinters were used as computer output devices, one or more null characters were sent at

1050-552: 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. For a long time they have not been included in the GNU C library (used by software on Linux), on the basis of allegedly being inefficient, encouraging the use of C strings (instead of some superior alternative form of string), and hiding other potential errors. Even while glibc hadn't added support, strlcat and strlcpy have been implemented in

1085-399: The standard library uses the convention that strings are null-terminated : a string of n characters is represented as an array of n + 1 elements, the last of which is a " NUL character" with numeric value 0. The only support for strings in the programming language proper is that the compiler translates quoted string constants into null-terminated strings. A string is defined as

C string - Misplaced Pages Continue

1120-628: 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. 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 use of these functions instead of standard ones. This has been speculated by some to be an attempt by Microsoft to lock developers into its platform. Experience with these functions has shown significant problems with their adoption and errors in usage, so

1155-499: The wide encoding, though the caller must still detect and call mbtowc twice for a single character. Later additions to the standard admit that the only conversion programmers are interested in is between UTF-8 and UTF-16 and directly provide this. The C standard library contains several functions for numeric conversions. The functions that deal with byte strings are defined in the stdlib.h header ( cstdlib header in C++). The functions that deal with wide strings are defined in

1190-850: The width of 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 UTF-32 , can be stored. (The standard requires a "type that holds any wide character", which on Windows no longer holds true since the UCS-2 to UTF-16 shift. This was recognized as a defect in the standard and fixed in C++.) C++11 and C11 add two types with explicit widths char16_t and char32_t . Variable-width encodings can be used in both byte strings and wide strings. String length and offsets are measured in bytes or wchar_t , not in "characters", which can be confusing to beginning programmers. UTF-8 and Shift JIS are often used in C byte strings, while UTF-16

1225-432: The zero terminator. Generally, the term string means a string where the code unit is of type char , 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

#944055