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 copia, concatenación , tokenización y búsqueda. 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 constantes de cadena entrecomilladas en 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 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.
Generalmente, 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 estaba pensado para Unicode , pero cada vez es más común utilizar UTF-8 en cadenas normales para Unicode.
Las cadenas se pasan a funciones pasando un puntero a la primera unidad de código. Dado que char*y wchar_t*son tipos diferentes, las funciones que procesan cadenas anchas son diferentes a las que procesan cadenas normales y tienen nombres diferentes.
Los literales de cadena ( "text"en el código fuente 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 de cero al final. En C90 L"text"produce una cuerda ancha. Un literal de cadena puede contener la unidad de código cero (una forma es colocarlo \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 que esas unidades de código fueron traducidas del 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 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 están definidas por el ancho de wchar_t. En la mayoría de las implementaciones, es de al menos 16 bits, por lo que se pueden almacenar wchar_ttodas las codificaciones de 16 bits, como UCS-2 . Si es de 32 bits, se pueden almacenar wchar_tcodificaciones 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 válido 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 utilizar 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 C, mientras que UTF-16 se usa a menudo en cadenas anchas de C cuando wchar_tson 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 resultar peligroso si las partes truncadas se interpretan mediante un 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 cuando los compiladores simplemente Copie lo que esté entre las comillas. Algunos compiladores o editores requerirán ingresar todos los caracteres que no sean ASCII como secuencias para cada byte de UTF-8 y/o para cada palabra de UTF-16. Desde C11 (y C++11), hay 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 destinado a almacenar caracteres UTF-8 y los tipos de caracteres con prefijo u8 y literales de cadena 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 usaba a menudo en lugar de "byte" para cadenas C, lo que lleva a muchos [ ¿ quién? ] creer que estas funciones de alguna manera no funcionan para UTF-8 . De hecho, todas las longitudes se definen en bytes y esto es cierto en todas las implementaciones, y estas funciones funcionan tan bien con codificaciones 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 usa "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, a diferencia del strprefijo.
La mayoría de las funciones que operan en cadenas C se declaran en el string.hencabezado ( cstringen C++), mientras que las funciones que operan en cadenas amplias de C se declaran en el wchar.hencabezado ( cwcharen C++). Estos encabezados también contienen declaraciones de funciones utilizadas para manejar los buffers de memoria; Por 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 del búfer cuando no se usan cuidadosa y adecuadamente. , 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 no constpuntero dentro 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 unmbstate_tobjeto, originalmente en la memoria estática (lo que hace que las funciones no sean seguras para subprocesos) y en adiciones posteriores la persona que llama debe mantener. Originalmente, esto estaba destinado a rastrear los estados de cambio en elmegabytecodificaciones, pero las modernas como UTF-8 no lo necesitan. Sin embargo, estas funciones fueron diseñadas bajo el supuesto de que elWCLa codificación no es una codificación de ancho variable y, por lo tanto, está diseñada para tratar exactamente unawchar_ta la vez, pasándolo por valor en lugar de usar un puntero de cadena. Como UTF-16 es una codificación de ancho variable, elmbstate_tse ha reutilizado para realizar un seguimiento de los pares sustitutos en la codificación amplia, aunque la persona que llama aún debe detectar y llamarmbtowcdos veces para un solo carácter. [80] [81] [82] 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 tratan con cadenas de bytes se definen en el stdlib.hencabezado ( cstdlibencabezado en C++). Las funciones que tratan con cadenas anchas se definen en el wchar.hencabezado ( cwcharencabezado en C++).
Las funciones strchr, bsearch, strpbrk, strrchr, y sus contrapartes amplias no son constantes correctas , ya que aceptan un strstrpuntero de cadena y devuelven un no puntero dentro de la cadena. Esto se ha solucionado en C23 . [95]memchrconstconst
Además, desde la Enmienda Normativa 1 (C95), atoxxlas funciones se consideran subsumidas por strtoxxxfunciones, por lo que ni C95 ni ninguna norma posterior proporciona versiones de caracteres amplios 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 del buffer, 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 función fue diseñada para esto (estaban destinadas a manipular buffers de cadena 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 expertos. programadores. [108]
El reemplazo [a] más popular son las funciones strlcaty strlcpy, 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 será necesario, lo que permite la detección del truncamiento y proporciona un tamaño para crear un nuevo búfer que no se truncará. Han sido criticados por supuestamente ser ineficientes, [111] alentar el uso de cadenas C (en lugar de alguna forma alternativa superior de cadena), [112] [113] y ocultar otros errores potenciales. [114] [115] En consecuencia, durante años, no se han incluido en la biblioteca GNU C (utilizada por el software en Linux), aunque eso sí se cambió. Las preguntas frecuentes de glibc Wiki sobre la inclusión de strlc{py|at} señalan que a partir de glibc 2.3.8, el código se confirmó [116] y, por lo tanto, se agregó. [117] El anuncio de disponibilidad de glibc 2.38 citó que las funciones "se espera que se agreguen a una futura versión POSIX". (El Austin Group Defect Tracker, ID 986 rastreó algunas discusiones sobre dichos planes para POSIX). Incluso si 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] La falta de soporte para la biblioteca GNU C había no impidió que varios autores de software lo usaran y empaquetaran un reemplazo, entre otros SDL , GLib , ffmpeg , rsync e incluso internamente en el kernel de Linux . Hay disponibles implementaciones de código abierto para estas funciones. [121] [122]
A veces se utilizan memcpy[53] o memmove[55] , ya que pueden ser más eficientes que strcpysi no verifican repetidamente 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 incluyen strcpy_sy strcat_s(junto con muchas otras). [123] Estas funciones se estandarizaron con algunos cambios menores como parte del C11 opcional (Anexo K) propuesto por ISO/IEC WDTR 24731. Estas funciones realizan varias comprobaciones, incluso 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 de tiempo de ejecución" especificada por el usuario, [124] que generalmente aborta el programa. [125] [126] Algunas funciones realizan operaciones destructivas antes de llamar al controlador de restricciones de tiempo de ejecución; por ejemplo, strcat_sestablece el destino en la cadena vacía, [127] lo que puede dificultar la recuperación de condiciones de error o su depuración. Estas funciones generaron muchas críticas porque al principio sólo se implementaron en Windows y al mismo tiempo Microsoft Visual C++ comenzó a generar mensajes de advertencia sugiriendo 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. [128] Aunque hay implementaciones de código abierto disponibles de estas funciones, estas funciones no están presentes en las bibliotecas comunes de Unix C. [129] La experiencia con estas funciones ha demostrado problemas importantes con su adopción y errores en el uso, por lo que se propone la eliminación del Anexo K para la próxima revisión del estándar C. [130]memset_s También se ha sugerido el uso de como una forma de evitar optimizaciones no deseadas del compilador. [131] [132]
strlcpy, frente a 38.644 usos strcpy_s(y 15.286.150 usos de strcpy). [ cita necesaria ]{{cite web}}: Mantenimiento CS1: ubicación ( enlace ){{cite web}}: Mantenimiento CS1: ubicación ( enlace ){{cite web}}: Mantenimiento CS1: ubicación ( enlace ){{cite web}}: Mantenimiento 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 excepción notable 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á cuánto tiempo son sus cadenas y, por lo tanto, puede usar memcpy (en lugar de strcpy).
{{cite web}}: Mantenimiento CS1: ubicación ( enlace ){{cite web}}: Mantenimiento CS1: ubicación ( enlace ){{cite web}}: Mantenimiento CS1: ubicación ( enlace )