solucionar - pagina no segura chrome solucion

¿Por qué POSIX especifica wctomb como no seguro para subprocesos, pero no mbtowc?

Question

En XSH 2.9.1 , wctomb se enumera como una de las funciones que no se requiere que sea segura para subprocesos. Sin embargo, la función de conversión opuesta, mbtowc , no aparece en la lista. En una implementación con codificaciones que usan estados de cambio, ninguna tiene una API segura para subprocesos, y no tiene sentido que se requiera que uno sea seguro para subprocesos y el otro no, mientras que ninguno puede ser seguro sin subprocesos sin prohibir las codificaciones con estado.

Del mismo modo para wcstombs (que está en la lista) y mbstowcs (que no está). Como estas dos funciones operan en cadenas completas que comienzan y terminan en el estado de cambio inicial, no tienen estado, sus API son seguras para subprocesos y, nuevamente, no tiene sentido que una dirección se especifique como segura para subprocesos pero no la otro.

¿Alguien puede arrojar algo de luz sobre esto?

Answer 1

Como anotó en la pregunta, wctomb tiene, o al menos se le permite tener, un "estado de cambio oculto": consulte http://pubs.opengroup.org/onlinepubs/009695399/functions/wctomb.html y compare esto a wcrtomb : http://pubs.opengroup.org/onlinepubs/009695399/functions/wcrtomb.html que tiene un puntero de "estado" explícito.

Básicamente, POSIX permite al programador implementar wctomb como una llamada a wcrtomb usando una variable static para mantener el estado de cambio. Si esa variable no es un elemento por hilo, no será seguro para subprocesos.

(todo esto es bastante obvio y está contenido en su pregunta, solo lo estoy repitiendo para mayor claridad)

Tenga en cuenta que ningún argumento de wctomb le otorga ningún tipo de control explícito del estado de cambio oculto (si lo hay). Específicamente, no puede restablecerlo al estado de inicio.

Pero ahora mire en mbtowc : http://pubs.opengroup.org/onlinepubs/009695399/functions/mbtowc.html donde el texto dice:

Para una codificación dependiente del estado, esta función se coloca en su estado inicial mediante una llamada para la cual su argumento de puntero de carácter, s, es un puntero nulo. Las llamadas subsiguientes con s como un puntero nulo harán que el estado interno de la función se altere según sea necesario. Una llamada con s como puntero nulo hará que esta función devuelva un valor distinto de cero si las codificaciones tienen dependencia de estado, y 0 en caso contrario. Si la implementación emplea bytes especiales para cambiar el estado de cambio, estos bytes no producirán códigos de caracteres anchos separados, sino que se agruparán con un carácter adyacente.

Es decir, le brindan una forma explícita de detectar y controlar el estado oculto (si existe). Así que incluso si existe y no es específico de un subproceso, puede "hacer su propio control" por así decirlo.

Si bien no puedo jurarlo, creo que esta es la razón por la que mbtowc no aparece como no seguro para subprocesos.

(¡Esta no es la forma en que habría escrito el texto en el estándar, sin embargo! Por otra parte, si lo hiciera, muchas de estas funciones ni siquiera existirían. :-))

Answer 2

Creo que esto se basa simplemente en el supuesto de que con un conjunto de datos codificados de caracteres amplios, el programador puede predecir cuánta memoria debe asignarse / liberarse por subproceso debido al ancho fijo del punto de código. Pero cuando se va en la otra dirección, dependiendo de la codificación, es posible que no sea "previsible" la cantidad de memoria que se debe asignar por adelantado, lo que crea mayor espacio para el error.

Actualización: después de haber encontrado una versión anterior del estándar, noté que hay una diferencia en la redacción en la http://pubs.opengroup.org/onlinepubs/009695399/functions/wctomb.html : "La función wctomb () no necesita ser reentrada. Una función que no es necesaria para ser reentrante no se requiere que sea seguro para subprocesos ". Creo que esto sugiere otra suposición implícita hecha en el estándar: mbtowc () es o debería ser reentrante ...

Answer 3

La asimetría fundamental es que ISO C requiere que los caracteres anchos tengan un ancho fijo (igual para todos los caracteres) y que la codificación no tenga estados de desplazamiento. En contraste, la codificación multibyte depende de la configuración regional y puede tener anchos de caracteres variables y también estados de cambio.

Las cuatro funciones tienen un estado interno mantenido entre las llamadas ( mbstowcs y wcstombs también tienen que hacerlo porque convierten solo un número específico de bytes en lugar de cadenas completas que de otro modo terminarían en el estado de cambio inicial).

Hay una diferencia sutil de en qué consiste el estado interno en el caso de las conversiones de cadena. Para mbstowcs , se mbstowcs un número entero de caracteres anchos en una sola llamada. Esto se debe a que los caracteres anchos tienen un ancho fijo, y también porque el parámetro n de la llamada se especifica en caracteres, no en bytes. En contraste, para wcstombs el parámetro n se especifica en bytes, no en caracteres de múltiples bytes. En consecuencia, el estado guardado para wcstombs debe incluir no solo el estado de desplazamiento, sino también el resto de un carácter multibyte de salida parcial. Debido a que el estado es, por lo tanto, de varias partes, las operaciones (carga y almacenamiento) en él no serán atómicas en una arquitectura típica sin un bloqueo adicional.

En este punto, es importante recordarnos que "seguridad de subprocesos" tiene un significado bastante técnico en POSIX, es decir, que las invocaciones paralelas son lógicamente serializables. No significa que el uso paralelo sea necesariamente muy útil. Como las cuatro funciones mantienen el estado interno, es difícil imaginar a una persona que llama que procesa una sola cadena lineal (a la vez) de izquierda a derecha, pero distribuyendo las llamadas a través de múltiples subprocesos. Esto se wcrtomb en la introducción de wcrtomb , wcrtomb , mbsrtowcs y wcstombs en la Enmienda 1 a la ISO C 89/90, con la bandera r que indica específicamente "reentrante".

No puedo explicar exactamente por qué tener un estado interno "accesible atómicamente" debería hacer que sea más fácil hacer que la llamada respectiva sea más fácil de implementar de una manera segura para subprocesos (porque a veces tiene que haber múltiples accesos, carga y almacenamiento, durante una sola llamada), pero tal vez se deba a que la carga del bloqueo adicional (y la recarga) solo se impone en la rama de código raramente visitada donde se está produciendo un estado de cambio real.

También hay otra trampa para explicar. Un subproceso concurrente puede llamar a setlocale cambiando la categoría de codificación de caracteres ( LC_CTYPE ) de la configuración regional. La norma ISO C especifica que tal acción hace que el estado actual (y, por cierto, incluso un estado bien capturado usando wcrtomb ) se vuelva indefinido. Esto se debe a que es posible que los estados de cambio de diferentes configuraciones regionales no se asignen entre sí de maneras útiles o específicas. Aunque este es un escenario de subprocesos que tiene el potencial de romper incluso la familia de funciones "reentrantes", no necesariamente representa un obstáculo para una implementación segura de subprocesos formal porque la configuración regional se puede almacenar en caché en cada llamada.

Answer 4

La forma común de "habilitar Unicode" un programa en C es usar wchar_t en lugar de char todas partes y llamar a las versiones de caracteres anchos de las funciones estándar de biblioteca de caracteres estrechos. Me gusta este enfoque porque está inmediatamente claro que una variable de tipo wchar_t* apunta a un objeto wchar_t o una cadena ancha, pero una variable de tipo char* puede apuntar a un objeto char , una cadena estrecha en la codificación nativa char, o una cadena multibyte en cualquiera de las docenas de codificaciones de caracteres compatibles. Con tantos significados fundamentalmente diferentes de char* , el programador debe tener mucho cuidado de no pasar, por ejemplo, una cadena multibyte codificada en UTF-8 a una función que espera una cadena estrecha, o pasar una cadena multibyte en la codificación actual a una función que espera una cadena codificada en UTF-8. Quizás la idea de asegurar que mbtowc y mbstowcs (funciones que convierten cadenas multibyte en cadenas anchas) sean seguras para subprocesos, pero no las funciones que se convierten de cadenas anchas en cadenas multibyte, es persuadir al programador para que siempre guarde los datos de cadena en la memoria del programa. formato de caracteres anchos, donde cada carácter representa exactamente un miembro del conjunto de caracteres de ejecución, en lugar de una combinación de cadenas estrechas y cadenas multibyte que utilizan posiblemente diferentes codificaciones de caracteres. Quizás los escritores habituales pensaban que ese es el enfoque más útil, o sería el más común.

Si considera la posibilidad de escribir software de servidor multihilo habilitado para Unicode en C, entonces seguir el patrón de mantener los datos de cadena en formato de cadena amplia ayuda a imponer una separación entre los datos de cadena leídos "del cable" y los datos de cadena en la memoria del programa. Cuando llega un mensaje nuevo que contiene una carga útil de datos de cadena, la rutina C que analiza el mensaje y su carga útil de cadena pueden usar funciones de E / S de caracteres estrechos con funciones de conversión de caracteres de multibytes a anchos para leer la cadena en la memoria del programa. Si varios subprocesos analizan los mensajes entrantes, como es típico, entonces es muy conveniente que mbstowcs sea ​​seguro para subprocesos.