¿Debe un búfer de bytes estar firmado o no firmado char buffer?

Question

¿Debería un buffer de bytes ser firmado char o unsigned char o simplemente un char buffer? ¿Alguna diferencia entre C y C++?

Gracias.

Answer 1

En caso de una memoria intermedia de bytes ser firmado carbón o unsigned char o simplemente un char buffer? Cualquier diferencia entre C y C++?

Una pequeña diferencia en cómo la trata la lengua. Una gran diferencia en cómo lo trata la convención.

• char = ASCII (o UTF-8, pero el signo numérico interpone en el camino allí) Pruebas datos
• unsigned char = byte
• signed char = rara vez se utiliza

Y hay código que se basa en en tal distinción. Hace apenas una semana o dos me encontré con un error donde los datos JPEG se corrompían porque se pasaba a la versión char* de nuestra función de codificación Base64 — que "útilmente" reemplazaba todo el UTF-8 no válido en la "cadena". Cambiar a BYTE aka unsigned char fue todo lo que se necesitó para solucionarlo.

Answer 2

Si obtiene un elemento en una variable más amplia, por supuesto tendrá extensión de signo o no.

Answer 3

debe y ... tiendo a prefieren sin firmar, ya que se siente más "crudo", menos atractivo para decir "bueno, eso es sólo un montón de pequeñas ints", si quiero hacer hincapié en el binario -idad de los datos.

No creo que alguna vez haya usado un signed char explícito para representar un búfer de bytes.

Por supuesto, una tercera opción es representar el búfer como void * tanto como sea posible. Muchas funciones de E/S comunes funcionan con void *, por lo que a veces la decisión de qué tipo de entero usar se puede encapsular por completo, lo cual es bueno.

Answer 4

Es mejor definirlo como char sin signo. De hecho, Win32 tipo BYTE se define como char sin signo. No hay diferencia entre C & C++ entre esto.

Answer 5

Hace varios años tuve un problema con una aplicación de consola C++ que imprimía caracteres de color para valores ASCII superiores a 128 y esto se solucionó cambiando de char a carácter no firmado, pero creo que se solucionaba manteniendo el tipo de caracteres también. .

Por ahora, la mayoría de las funciones C/C++ usan caracteres y entiendo ambos idiomas mucho mejor ahora, entonces uso caracteres en la mayoría de los casos.

Answer 6

Depende.

Si el búfer está destinado a contener texto, entonces probablemente tenga sentido declararlo como una matriz de char y dejar que la plataforma decida por usted si está firmado o no de manera predeterminada. Eso le dará menos problemas para pasar los datos dentro y fuera de la biblioteca de tiempo de ejecución de la implementación, por ejemplo.

Si el búfer está destinado a contener datos binarios, depende de cómo se vaya a utilizar. Por ejemplo, si los datos binarios son realmente una matriz empaquetada de muestras de datos que tienen medidas de ADC de punto fijo de 8 bits, entonces signed char sería lo mejor.

En la mayoría de los casos del mundo real, el búfer es solo eso, un búfer, y realmente no le importan los tipos de bytes individuales porque llenó el búfer en una operación masiva, y está a punto de aprobar a un analizador para interpretar la compleja estructura de datos y hacer algo útil. En ese caso, declarelo de la manera más simple.

Answer 7

¿De verdad te importa? Si no lo hace, simplemente use el valor predeterminado (char) y no ocupe su código con asuntos sin importancia. De lo contrario, los futuros mantenedores se preguntarán por qué usaste firmado (o sin firmar). Haz su vida más simple.

Answer 8

Si en realidad es un búfer de bytes de 8 bits, en lugar de una cadena en la configuración regional predeterminada de la máquina, entonces usaría uint8_t. No es que haya muchas máquinas en las que un carácter no sea un byte (o un byte a octeto), sino que la declaración 'esto es un buffer de octetos' en lugar de 'esto es un string' es a menudo documentación útil.

Answer 9

Para una máxima portabilidad siempre use char sin signo.Hay un par de instancias donde esto podría entrar en juego. Los datos serializados compartidos entre sistemas con diferentes tipos de endian inmediatamente vienen a la mente. Al realizar mayúsculas o minúsculas los valores es otro.

Answer 10

que puedes usar ya sea carbón o unsigned char pero nunca firmado carbón. El estándar tiene la siguiente en 3,9/2

Para cualquier objeto (distinto de un subobjeto de la clase base) de tipo POD T, si o no el objeto contiene un valor válido de tipo T, el subyacente bytes (1.7) que componen el objeto puede se copiarán en una matriz de char o unsigned char.If el contenido de la matriz de char o unsigned char se copia de nuevo en el objeto, el objeto deberá mantener posteriormente su valor original.

Answer 11

Si desea almacenar datos binarios arbitrarios, debe usar unsigned char. Es el único tipo de datos que garantiza que el estándar C no tiene bits de relleno. Cada otro tipo de datos puede contener bits de relleno en su representación de objeto (que es el que contiene todos los bits de un objeto, en lugar de solo aquellos que determinan un valor). El estado de los bits de relleno no está especificado y no se utilizan para almacenar valores. Por lo tanto, si lee usando char algunos datos binarios, las cosas se reducirán al rango de valores de un carácter (interpretando solo los bits de valor), pero aún puede haber bits que simplemente se ignoran pero aún están allí y leídos por memcpy. Es muy parecido a rellenar bits en objetos reales de estructura. El tipo unsigned char está garantizado para no contener ésos. Así se desprende de 5.2.4.2.1/2 (C99 TC2, n1124 aquí):

Si el valor de un objeto de tipo char es tratado como un entero con signo cuando se utiliza en una expresión , el valor de CHAR_MIN será la misma que la de SCHAR_MIN y el valor de CHAR_MAX será el mismo que el de SCHAR_MAX. De lo contrario, el valor de CHAR_MIN será 0 y el valor de CHAR_MAX será el mismo que el de UCHAR_MAX. El valor será igual UCHAR_MAX2^CHAR_BIT − 1

Desde la última frase se deduce que no hay espacio libre para cualquier bits de relleno. Si usa char como el tipo de su búfer, también tiene el problema de desbordamientos: Asignación de cualquier valor explícitamente a un elemento que está en el rango de 8 bits, por lo que puede esperar que dicha asignación sea correcta, pero no dentro del rango de char, que es CHAR_MIN .. CHAR_MAX, dicha conversión se desborda y causa resultados de implementación definidos, incluido el aumento de las señales.

Incluso si hay algún problema con respecto a lo anterior probablemente no mostrarían en las implementaciones reales (sería una muy mala calidad de aplicación ), que son los mejores para usar el tipo correcto desde el principio en adelante, que es unsigned char.

Para cadenas, sin embargo, el tipo de datos de elección es char, que se entenderá por cadena y funciones de impresión.Usar signed char para estos propósitos me parece una decisión incorrecta.

Para obtener más información, lea this proposal que contiene una solución para una próxima versión del estándar C que eventualmente requerirá que signed char tampoco tenga ningún relleno. Ya está incorporado en el working paper.

Answer 12

La elección de int8_t vs uint8_t es similar a cuando se compara un ptr a ser NULL.

---

Desde el punto de vista de la funcionalidad, en comparación con NULL es lo mismo que comparar a 0 porque NULL es un #define para 0.

Pero, personalmente, desde un punto de vista de estilo de codificación, elijo comparar mis punteros a NULL porque el #define NULL connota a la persona que mantiene el código que se está comprobando para un puntero erróneo ...

VS

cuando alguien ve una comparación a 0 connota que son buscando un valor específico.

---

Por la razón anterior, usaría uint8_t.

Answer 13

Si le miente al compilador, lo castigará.

Si el búfer contiene datos que están de paso, y no los manipulará de ninguna manera, no importa.

Sin embargo, si tiene que operar en el contenido del búfer, la declaración de tipo correcta simplificará su código. No "int val = buf [i] & 0xff;" disparates.

Por lo tanto, piense en qué son realmente los datos y cómo debe usarlos.

Answer 14

typedef char byte; 

Ahora usted puede hacer su conjunto sea de byte s. Es obvio para todos lo que quieres decir, y no pierdes ninguna funcionalidad.

Sé que es un poco tonto, pero hace que su código lea 100% como lo desea.