El lenguaje de programación C tiene un conjunto de funciones que implementan operaciones sobre cadenas (cadenas de caracteres y cadenas de bytes) en su biblioteca estándar . Se admiten varias 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 NUL " con valor numérico 0.
El único soporte para cadenas en el lenguaje de programación propiamente dicho es que el compilador traduce las constantes de cadena entre comillas en cadenas terminadas en nulo.
Una cadena se define como una secuencia contigua de unidades de código terminadas en la primera unidad de código cero (a menudo denominada 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 ve 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 es siempre una unidad de código más que la longitud, ya que se necesita espacio para almacenar el terminador cero.
En general, el término cadena significa una cadena donde la unidad de código es de tipo char, que es exactamente de 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 es de 16 o 32 bits en las máquinas modernas. Esto fue pensado para Unicode , pero es cada vez más común utilizar UTF-8 en cadenas normales para Unicode.
Las cadenas se pasan a las funciones pasando un puntero a la primera unidad de código. Como char *y wchar_t *son tipos diferentes, las funciones que procesan cadenas anchas son diferentes de las que procesan cadenas normales y tienen nombres diferentes.
Los literales de cadena ( "text"en el código fuente de C) se convierten en matrices durante la compilación. [2] El resultado es una matriz de unidades de código que contiene todos los caracteres más una unidad de código cero final. En C90 L"text"produce una cadena ancha. Un literal de cadena puede contener la unidad de código cero (una forma es ponerlo \0en la fuente), pero esto hará que la cadena termine en ese punto. El resto del literal se colocará en la memoria (con otra unidad de código cero agregada al final) pero es imposible saber si esas unidades de código se tradujeron del literal de cadena, por lo tanto, dicho código fuente no es un literal de cadena. [3]
Cada cadena termina en la primera ocurrencia de la unidad de código cero del tipo apropiado ( charo wchar_t). En consecuencia, una cadena de bytes ( char*) puede contener caracteres no 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 puede ser distinta de cero, su byte alto o bajo puede ser cero). Las codificaciones que se pueden almacenar en cadenas anchas se definen por el ancho de wchar_t. En la mayoría de las implementaciones, wchar_tes de al menos 16 bits, por lo que se pueden almacenar todas las codificaciones de 16 bits, como UCS-2 . Si wchar_tes de 32 bits, se pueden almacenar codificaciones de 32 bits, como UTF-32 . (El estándar requiere un "tipo que admita cualquier carácter ancho", lo que en Windows ya no es válido desde el cambio de UCS-2 a UTF-16. Esto fue reconocido como un defecto en el estándar y corregido 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 utilizar tanto en cadenas de bytes como en cadenas anchas. La longitud de la cadena y los desplazamientos se miden en bytes o wchar_tno en "caracteres", lo que puede resultar confuso para los programadores principiantes. UTF-8 y Shift JIS se utilizan a menudo en cadenas de bytes de C, mientras que UTF-16 se utiliza a menudo en cadenas anchas de C cuando wchar_tes de 16 bits. Truncar cadenas con caracteres de ancho variable mediante funciones como strncpypuede producir secuencias no válidas al final de la cadena. Esto puede ser inseguro si las partes truncadas son interpretadas por un código que supone 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 caracteres y cadenas literales con prefijo u8 se cambiaron a y respectivamente.char foo[512] = "φωωβαρ";wchar_t foo[512] = L"φωωβαρ";wchar_tchar\xNN\uNNNNu8char foo[512] = u8"φωωβαρ";char8_tchar8_tchar8_t[]
En la documentación histórica, el término "carácter" se utilizaba a menudo en lugar de "byte" para las cadenas de C, lo que lleva a muchos [¿ quiénes? ] a creer que estas funciones de alguna manera no funcionan para UTF-8 . De hecho, todas las longitudes se definen como en bytes y esto es cierto en todas las implementaciones, y estas funciones funcionan tanto con UTF-8 como con codificaciones de un solo byte. La documentación de BSD se ha corregido para dejar esto claro, pero la documentación de POSIX, Linux y Windows todavía utiliza "carácter" en muchos lugares donde "byte" o "wchar_t" es el término correcto.
Las funciones para manejar buffers de memoria pueden procesar secuencias de bytes que incluyen bytes nulos como parte de los datos. Los nombres de estas funciones suelen comenzar con mem, en lugar del strprefijo.
La mayoría de las funciones que operan en cadenas de C se declaran en el string.hencabezado ( cstringen C++), mientras que las funciones que operan en cadenas de C de ancho amplio se declaran en el wchar.hencabezado ( cwcharen C++). Estos encabezados también contienen declaraciones de funciones utilizadas para manejar buffers de memoria; por lo tanto, el nombre es algo inapropiado.
Las funciones declaradas en string.hson extremadamente populares ya que, como parte de la biblioteca estándar de C , se garantiza que funcionan en cualquier plataforma que admita C. Sin embargo, existen algunos problemas de seguridad con estas funciones, como posibles desbordamientos de búfer cuando no se usan con cuidado y de manera adecuada, lo que hace que los programadores prefieran variantes más seguras y posiblemente menos portátiles, de las cuales algunas populares se enumeran a continuación. Algunas de estas funciones también violan la corrección constante al aceptar un constpuntero de cadena y devolver un puntero no constdentro de la cadena. Para corregir esto, algunas se han separado en dos funciones sobrecargadas en la versión C++ de la biblioteca estándar.
Todas estas funciones necesitan unaestado_mbobjeto, originalmente en memoria estática (haciendo que las funciones no sean seguras para subprocesos) y en adiciones posteriores el llamador debe mantener. Esto originalmente estaba destinado a rastrear estados de cambio en elmegabytecodificaciones, pero las modernas como UTF-8 no lo necesitan. Sin embargo, estas funciones se diseñaron asumiendo que elWCLa codificación no es una codificación de ancho variable y, por lo tanto, está diseñada para tratar exactamente con unachar_t_esa la vez, pasándolo por valor en lugar de usar un puntero de cadena. Como UTF-16 es una codificación de ancho variable,estado_mbSe ha reutilizado para realizar un seguimiento de los pares sustitutos en la codificación amplia, aunque el llamador aún debe detectar y llamarmbtowcdos veces para un solo carácter. [80] [81] [82] Las adiciones posteriores al estándar admiten que la única conversión que interesa a los programadores es entre UTF-8 y UTF-16 y la proporcionan directamente.
La biblioteca estándar de C contiene varias funciones para conversiones numéricas. Las funciones que se ocupan de cadenas de bytes se definen en el stdlib.hencabezado ( cstdlibheader en C++). Las funciones que se ocupan de cadenas anchas se definen en el wchar.hencabezado ( cwcharheader en C++).
Las funciones strchr, bsearch, strpbrk, strrchr, strstr, memchry sus contrapartes amplias no son constantes-correctas , ya que aceptan un constpuntero de cadena y devuelven un no- constpuntero dentro de la cadena. Esto se ha corregido en C23 . [95]
Además, desde la Enmienda Normativa 1 (C95), atoxxlas funciones se consideran subsumidas por strtoxxxfunciones, por lo que ni la C95 ni ninguna norma posterior proporciona versiones de caracteres anchos de estas funciones. El argumento en contra atoxxes que no diferencian entre un error y un 0. [96]
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 (estaban destinadas a manipular búferes de cadenas de tamaño fijo con relleno nulo, un formato de datos menos comúnmente usado 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]
Las funciones de reemplazo más populares 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 la detección del 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 C de GNU (usada por el software en Linux), sobre la base de que supuestamente son ineficientes, [113] fomentan el uso de cadenas de C (en lugar de alguna forma alternativa superior de cadena), [114] [115] y ocultan otros errores potenciales. [116] [117] Incluso cuando glibc no había agregado soporte, strlcat y strlcpy se han implementado en varias otras bibliotecas de C, incluidas las de OpenBSD, FreeBSD , NetBSD , Solaris , OS X y QNX , así como en bibliotecas de C alternativas para Linux, como libbsd, introducida en 2008, [118] y musl , introducida en 2011, [119] [120] y el código fuente se agregó directamente a otros proyectos como SDL , GLib , ffmpeg , rsync e incluso internamente en el kernel de Linux . Esto cambió en 2024, las preguntas frecuentes de glibc señalan que a partir de glibc 2.38, el código se ha confirmado [121] y, por lo tanto, se agregó. [122] Estas funciones se estandarizaron como parte de POSIX.1-2024, [123] el Austin Group Defect Tracker ID 986 rastreó algunas discusiones sobre dichos planes para POSIX.
A veces se utilizan memcpy[53] o memmove[55] , ya que pueden ser más eficientes que strcpylos que no comprueban repetidamente si hay valores NUL (esto es menos cierto en los procesadores modernos). Dado que necesitan una longitud de búfer como parámetro, la configuración correcta de este parámetro puede evitar desbordamientos de búfer.
Como parte de su Ciclo de vida de desarrollo de seguridad 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 del C11 opcional (Anexo K) propuesto por ISO/IEC WDTR 24731. [125] Estas funciones realizan varias comprobaciones, incluida la de si la cadena es demasiado larga para caber en el búfer. Si las comprobaciones fallan, se llama a una función "controlador de restricción de tiempo de ejecución" especificada por el usuario, [126] que generalmente 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 es un intento de Microsoft de encerrar a los desarrolladores en 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 propone la eliminación del Anexo K para la próxima revisión del estándar C. [130] Se ha sugerido su uso memset_scomo una forma de evitar optimizaciones no deseadas del compilador. [131] [132]
strlcpy, frente a 38.644 usos de strcpy_s(y 15.286.150 usos de strcpy). [ cita requerida ]{{cite web}}: Mantenimiento de CS1: ubicación ( enlace ){{cite web}}: Mantenimiento de CS1: ubicación ( enlace ){{cite web}}: Mantenimiento de CS1: ubicación ( enlace ){{cite web}}: Mantenimiento de CS1: ubicación ( enlace )Esta API [strlcpy y strlcat] ha sido adoptada por la mayoría de los sistemas operativos modernos y muchos paquetes de software independientes [...]. La notable excepción es la biblioteca C estándar de GNU, glibc, cuyo mantenedor se niega rotundamente a incluir estas API mejoradas, etiquetándolas como "basura BSD terriblemente ineficiente", a pesar de la evidencia previa de que son más rápidas en la mayoría de los casos que las API que reemplazan.
El manejo correcto de cadenas significa que siempre sabrás qué tan largas son tus cadenas y, por lo tanto, podrás usar memcpy (en lugar de strcpy).
{{cite web}}: Mantenimiento de CS1: ubicación ( enlace ){{cite web}}: Mantenimiento de CS1: ubicación ( enlace )