Manejo de cadenas en C

El lenguaje de programación C cuenta con un conjunto de funciones que implementan operaciones con cadenas (de caracteres y de bytes) en su biblioteca estándar . Se admiten diversas operaciones, como copiar, concatenar , tokenizar y buscar. Para las cadenas de caracteres, la biblioteca estándar utiliza la convención de que las cadenas terminan en nulo : una cadena de n caracteres se representa como una matriz de n + 1 elementos, el último de los cuales es un carácter nulo con valor numérico 0.

El único soporte para cadenas en el lenguaje de programación propiamente dicho consiste en que el compilador traduce las constantes de cadena entre comillas a cadenas terminadas en nulo.

Una cadena se define como una secuencia contigua de unidades de código terminada por la primera unidad de código cero (a menudo llamada unidad de código NUL ). ^{[ 1 ]} Esto significa que una cadena no puede contener la unidad de código cero, ya que la primera que se encuentra marca el final de la cadena. La longitud de una cadena es el número de unidades de código antes de la unidad de código cero. ^{[ 1 ]} La memoria ocupada por una cadena siempre es una unidad de código más que su longitud, ya que se necesita espacio para almacenar el terminador cero.

Generalmente, el término cadena se refiere a una cadena cuya unidad de código es de tipo char, que equivale exactamente a 8 bits en todas las máquinas modernas. C90 define cadenas anchas ^{[ 1 ]} que utilizan una unidad de código de tipo wchar_t, que equivale a 16 o 32 bits en las máquinas modernas. Esto se concibió para Unicode , pero cada vez es más común utilizar UTF-8 en cadenas normales para Unicode.

Las cadenas se pasan a las funciones mediante un puntero a la primera unidad de código. Dado que char*y wchar_t*son de tipos diferentes, las funciones que procesan cadenas anchas son distintas de las que procesan cadenas normales y tienen nombres diferentes.

Los literales de cadena ( "text"en el código fuente C) se convierten en arreglos ( char[]en C o const char[]en C++) durante la compilación. ^{[ 2 ]} El resultado es un arreglo de unidades de código que contiene todos los caracteres más una unidad de código cero final. En C90 L"text"se produce una cadena ancha. Un literal de cadena puede contener la unidad de código cero (una forma es insertarla \0en el código fuente), pero esto hará que la cadena termine en ese punto. El resto del literal se colocará en memoria (con otra unidad de código cero añadida al final), pero es imposible saber que esas unidades de código se tradujeron desde el literal de cadena; por lo tanto, dicho código fuente no es un literal de cadena. ^{[ 3 ]}

Cada cadena termina en la primera aparición de la unidad de código cero del tipo apropiado ( charo wchar_t). En consecuencia, una cadena de bytes ( char*) puede contener caracteres que no sean NUL en ASCII o cualquier extensión ASCII , pero no caracteres en codificaciones como UTF-16 (aunque una unidad de código de 16 bits podría ser distinta de cero, su byte alto o bajo podría ser cero). Las codificaciones que se pueden almacenar en cadenas anchas están definidas por el ancho de wchar_t. En la mayoría de las implementaciones, wchar_tes de al menos 16 bits, por lo que todas las codificaciones de 16 bits, como UCS-2 , se pueden almacenar. Si wchar_tes de 32 bits, entonces se pueden almacenar codificaciones de 32 bits, como UTF-32 . (El estándar requiere un "tipo que contenga cualquier carácter ancho", lo cual en Windows ya no es cierto desde el cambio de UCS-2 a UTF-16. Esto se reconoció como un defecto en el estándar y se corrigió en C++.) ^{[ 4 ]} C++11 y C11 agregan dos tipos con anchos explícitos char16_ty char32_t. ^{[ 5 ]}

Las codificaciones de ancho variable se pueden usar tanto en cadenas de bytes como en cadenas anchas. La longitud de la cadena y los desplazamientos se miden en bytes o wchar_t, no en "caracteres", lo que puede resultar confuso para los programadores principiantes. UTF-8 y Shift JIS se usan a menudo en cadenas de bytes de C, mientras que UTF-16 se usa a menudo en cadenas anchas de C cuando wchar_tes de 16 bits. Truncar cadenas con caracteres de ancho variable usando funciones como strncpypuede producir secuencias no válidas al final de la cadena. Esto puede ser inseguro si las partes truncadas son interpretadas por código que asume que la entrada es válida.

El soporte para literales Unicode como (UTF-8) o (UTF-16 o UTF-32, depende de ) está definido por la implementación, ^{[ 6 ]} y puede requerir que el código fuente esté en la misma codificación, especialmente para donde los compiladores podrían simplemente copiar lo que esté entre las comillas. Algunos compiladores o editores requerirán ingresar todos los caracteres no ASCII como secuencias para cada byte de UTF-8, y/o para cada palabra de UTF-16. Desde C11 (y C++11), está disponible un nuevo prefijo literal que garantiza UTF-8 para un literal de cadena de bytes, como en . ^{[ 7 ]} Desde C++20 y C23 , se agregó un tipo que está destinado a almacenar caracteres UTF-8 y los tipos de literales de caracteres y cadenas con prefijo u8 se cambiaron a y respectivamente.charfoo[512]="φωωβαρ";wchar_tfoo[512]=L"φωωβαρ";wchar_tchar\xNN\uNNNNu8charfoo[512]=u8"φωωβαρ";char8_tchar8_tchar8_t[]

Varios estándares relacionados han ampliado la funcionalidad de manejo de cadenas proporcionada por el estándar C, incluidos BSD , SVID y POSIX . Algunas de estas funciones se han añadido en estándares C más recientes (por ejemplo, C11 y C23 ).

A pesar de la necesidad bien establecida de reemplazar strcat^{[ 22 ]} y strcpy^{[ 18 ]} con funciones que no permitan desbordamientos de búfer, no ha surgido ningún estándar aceptado. Esto se debe en parte a la creencia errónea de muchos programadores de C de que strncaty strncpytienen el comportamiento deseado; sin embargo, ninguna de las funciones fue diseñada para esto (fueron destinadas a manipular búferes de cadena de tamaño fijo con relleno nulo, un formato de datos menos común en el software moderno), y el comportamiento y los argumentos no son intuitivos y a menudo están escritos incorrectamente incluso por programadores expertos. ^{[ 108 ]}

Los reemplazos más populares ^{[ a ] son ​​las funciones} strlcat^{[ 111 ]} y strlcpy^{[ 112 ]} , que aparecieron en OpenBSD 2.4 en diciembre de 1998. ^{[ 108 ]} Estas funciones siempre escriben un NUL en el búfer de destino, truncando el resultado si es necesario, y devuelven el tamaño del búfer que se necesitaría, lo que permite detectar el truncamiento y proporciona un tamaño para crear un nuevo búfer que no se truncará. Durante mucho tiempo no se han incluido en la biblioteca GNU C (utilizada por el software en Linux), basándose en que supuestamente son ineficientes, ^{[ 113 ]} fomentan el uso de cadenas C (en lugar de alguna forma alternativa superior de cadena), ^{[ 114 ] [ 115 ]} y ocultan otros posibles errores. ^{[ 116 ] [ 117 ]} Incluso cuando glibc no había agregado soporte, strlcat y strlcpy se han implementado en varias otras bibliotecas C, incluidas las de OpenBSD, FreeBSD , NetBSD , Solaris , OS X y QNX , así como en bibliotecas C alternativas para Linux, como libbsd , introducida en 2008, ^{[ 118 ]} y musl , introducida en 2011, ^{[ 119 ] [ 120 ]} y el código fuente agregado directamente a otros proyectos como SDL , GLib , ffmpeg , rsync , e incluso internamente en el kernel de Linux . Esto cambió en 2024, las FAQ de glibc señalan que a partir de glibc 2.38, el código se ha confirmado ^{[ 121 ]} y por lo tanto se ha agregado. ^{[ 122 ]} Estas funciones se estandarizaron como parte de POSIX.1-2024, ^{[ 123 ]} el Rastreador de defectos de Austin Group ID 986 registró algunas discusiones sobre tales planes para POSIX.

Como parte de su ciclo de vida de desarrollo seguro de 2004 , Microsoft introdujo una familia de funciones "seguras" que incluían strcpy_sy strcat_s(junto con muchas otras). ^{[ 124 ]} Estas funciones se estandarizaron con algunos cambios menores como parte de la C11 opcional (Anexo K) propuesta por ISO/IEC WDTR 24731. ^{[ 125 ]} Estas funciones realizan varias comprobaciones, incluida si la cadena es demasiado larga para caber en el búfer. Si las comprobaciones fallan, se llama a una función de "controlador de restricciones en tiempo de ejecución" especificada por el usuario, ^{[ 126 ]} que normalmente aborta el programa. ^{[ 127 ] [ 128 ]} Estas funciones atrajeron considerables críticas porque inicialmente se implementaron solo en Windows y, al mismo tiempo, Microsoft Visual C++ comenzó a producir mensajes de advertencia que sugerían el uso de estas funciones en lugar de las estándar. Algunos han especulado que esto fue un intento de Microsoft de obligar a los desarrolladores a usar su plataforma. ^{[ 129 ]} La experiencia con estas funciones ha mostrado problemas significativos con su adopción y errores en su uso, por lo que se propuso la eliminación del Anexo K para la próxima revisión del estándar C. ^{[ 130 ]} Se ha sugerido el uso de memset_scomo una forma de evitar optimizaciones no deseadas del compilador. ^{[ 131 ] [ 132 ]}

• Sintaxis de C §  Cadenas : sintaxis del código fuente, incluidas las secuencias de escape con barra invertida 
• Manejo de cadenas en C++
• funciones de cadena
• Expresiones regulares compatibles con Perl (PCRE)

• Copia rápida de memoria en C , múltiples ejemplos de código en C para diferentes tipos de arquitecturas de instrucciones de CPU.