¿Cuál es la forma correcta de convertir 2 bytes a un entero de 16 bits con signo?

En esta respuesta , zwol hizo esta afirmación:

La forma correcta de convertir dos bytes de datos de una fuente externa en un entero con signo de 16 bits es con funciones auxiliares como esta:

#include <stdint.h>

int16_t be16_to_cpu_signed(const uint8_t data[static 2]) {
    uint32_t val = (((uint32_t)data[0]) << 8) | 
                   (((uint32_t)data[1]) << 0);
    return ((int32_t) val) - 0x10000u;
}

int16_t le16_to_cpu_signed(const uint8_t data[static 2]) {
    uint32_t val = (((uint32_t)data[0]) << 0) | 
                   (((uint32_t)data[1]) << 8);
    return ((int32_t) val) - 0x10000u;
}

Cuál de las funciones anteriores es apropiada depende de si la matriz contiene una representación little endian o big endian. Endianness no es el problema en cuestión aquí, me pregunto por qué zwol resta 0x10000udel uint32_tvalor convertido a int32_t.

¿Por qué es esta la forma correcta ?

¿Cómo evita el comportamiento definido de implementación cuando se convierte al tipo de retorno?

Como puede asumir la representación del complemento de 2, ¿cómo podría fallar este elenco más simple? return (uint16_t)val;

Lo que está mal con esta solución ingenua:

int16_t le16_to_cpu_signed(const uint8_t data[static 2]) {
    return (uint16_t)data[0] | ((uint16_t)data[1] << 8);
}

Si intes de 16 bits, su versión se basa en el comportamiento definido por la implementación si el valor de la expresión en la returndeclaración está fuera de rango int16_t.

Sin embargo, la primera versión también tiene un problema similar; por ejemplo, si int32_tes un typedef para int, y los bytes de entrada son ambos 0xFF, entonces el resultado de la resta en la declaración de retorno es lo UINT_MAXque causa un comportamiento definido por la implementación cuando se convierte a int16_t.

En mi humilde opinión, la respuesta a la que se vincula tiene varios problemas importantes.

Esto debe ser pedagógicamente correcto y funcionar también en plataformas que usan bit de signo o representaciones de complemento de 1 , en lugar del complemento habitual de 2 . Se supone que los bytes de entrada están en el complemento de 2.

int le16_to_cpu_signed(const uint8_t data[static 2]) {
    unsigned value = data[0] | ((unsigned)data[1] << 8);
    if (value & 0x8000)
        return -(int)(~value) - 1;
    else
        return value;
}

Debido a la sucursal, será más costoso que otras opciones.

Lo que esto logra es que evita cualquier suposición sobre cómo la intrepresentación se relaciona con la unsignedrepresentación en la plataforma. La conversión a intse requiere para preservar el valor aritmético de cualquier número que se ajuste al tipo de destino. Debido a que la inversión asegura que el bit superior del número de 16 bits será cero, el valor se ajustará. Luego, el unario -y la resta de 1 aplican la regla usual para la negación del complemento de 2. Dependiendo de la plataforma, INT16_MINaún podría desbordarse si no cabe en el inttipo en el destino, en cuyo caso longdebe usarse.

La diferencia con la versión original en la pregunta viene en el tiempo de regreso. Si bien el original siempre se resta 0x10000y el complemento de 2 permite que el desbordamiento firmado lo envuelva al int16_trango, esta versión tiene el explícito ifque evita el wrapover firmado (que no está definido ).

Ahora en la práctica, casi todas las plataformas en uso hoy en día usan la representación del complemento 2. De hecho, si la plataforma cumple con el estándar stdint.hque defineint32_t , debe usar el complemento de 2 para ello. Donde este enfoque a veces resulta útil es con algunos lenguajes de secuencias de comandos que no tienen tipos de datos enteros en absoluto: puede modificar las operaciones que se muestran arriba para los flotantes y dará el resultado correcto.

Otro método: usar union:

union B2I16
{
   int16_t i;
   byte    b[2];
};

En programa:

...
B2I16 conv;

conv.b[0] = first_byte;
conv.b[1] = second_byte;
int16_t result = conv.i;

first_bytey second_bytepuede intercambiarse según el modelo endian pequeño o grande. Este método no es mejor pero es una de las alternativas.

Los operadores aritméticos shift y bit a bit o en expresión (uint16_t)data[0] | ((uint16_t)data[1] << 8)no funcionan en tipos más pequeños int, de modo que esos uint16_tvalores se promueven a int(o unsignedsi sizeof(uint16_t) == sizeof(int)). Sin embargo, eso debería dar la respuesta correcta, ya que solo los 2 bytes inferiores contienen el valor.

Otra versión pedagógicamente correcta para la conversión big-endian a little-endian (suponiendo CPU little-endian) es:

#include <string.h>
#include <stdint.h>

int16_t be16_to_cpu_signed(const uint8_t data[2]) {
    int16_t r;
    memcpy(&r, data, sizeof r);
    return __builtin_bswap16(r);
}

memcpyse utiliza para copiar la representación de int16_ty esa es la forma de hacerlo que cumple con los estándares. Esta versión también se compila en 1 instrucción movbe, ver ensamblaje .

Aquí hay otra versión que se basa solo en comportamientos portátiles y bien definidos (el encabezado #include <endian.h>no es estándar, el código sí lo es):

#include <endian.h>
#include <stdint.h>
#include <string.h>

static inline void swap(uint8_t* a, uint8_t* b) {
    uint8_t t = *a;
    *a = *b;
    *b = t;
}
static inline void reverse(uint8_t* data, int data_len) {
    for(int i = 0, j = data_len / 2; i < j; ++i)
        swap(data + i, data + data_len - 1 - i);
}

int16_t be16_to_cpu_signed(const uint8_t data[2]) {
    int16_t r;
#if __BYTE_ORDER == __LITTLE_ENDIAN
    uint8_t data2[sizeof r];
    memcpy(data2, data, sizeof data2);
    reverse(data2, sizeof data2);
    memcpy(&r, data2, sizeof r);
#else
    memcpy(&r, data, sizeof r);
#endif
    return r;
}

La versión little-endian se compila con una sola movbeinstrucción clang, la gccversión es menos óptima, vea el ensamblaje .

Quiero agradecer a todos los contribuyentes por sus respuestas. Esto es a lo que se reduce el trabajo colectivo:

1. Según el estándar C 7.20.1.1 Tipos enteros de ancho exacto : tipos uint8_t, int16_ty uint16_tdeben usar la representación del complemento a dos sin ningún bit de relleno, por lo que los bits reales de la representación son inequívocamente los de los 2 bytes en la matriz, en el orden especificado por Los nombres de las funciones.
2. calcular el valor de 16 bits sin signo con (unsigned)data[0] | ((unsigned)data[1] << 8)(para la versión little endian) se compila en una sola instrucción y produce un valor de 16 bits sin signo.
3. Según el Estándar C 6.3.1.3 Enteros con y sin signo : la conversión de un valor de tipo uint16_ta tipo con signo int16_ttiene un comportamiento definido de implementación si el valor no está en el rango del tipo de destino. No se hacen disposiciones especiales para los tipos cuya representación se define con precisión.
4. Para evitar este comportamiento definido de implementación, se puede probar si el valor sin signo es mayor que INT_MAXy calcular el valor firmado correspondiente restando 0x10000. Hacer esto para todos los valores sugeridos por zwol puede producir valores fuera del rango de int16_tcon el mismo comportamiento definido de implementación.
5. probar el 0x8000bit explícitamente hace que los compiladores produzcan código ineficiente.
6. Una conversión más eficiente sin un comportamiento definido de implementación utiliza el tipo de punteo a través de un sindicato, pero el debate sobre la definición de este enfoque aún está abierto, incluso a nivel del Comité de la Norma C.
7. Tipo de juegos de palabras puede ser realizada de forma portátil y con el comportamiento define utilizando memcpy.

Combinando los puntos 2 y 7, aquí hay una solución portátil y totalmente definida que se compila eficientemente en una sola instrucción con gcc y clang :

#include <stdint.h>
#include <string.h>

int16_t be16_to_cpu_signed(const uint8_t data[2]) {
    int16_t r;
    uint16_t u = (unsigned)data[1] | ((unsigned)data[0] << 8);
    memcpy(&r, &u, sizeof r);
    return r;
}

int16_t le16_to_cpu_signed(const uint8_t data[2]) {
    int16_t r;
    uint16_t u = (unsigned)data[0] | ((unsigned)data[1] << 8);
    memcpy(&r, &u, sizeof r);
    return r;
}

Asamblea de 64 bits :

be16_to_cpu_signed(unsigned char const*):
        movbe   ax, WORD PTR [rdi]
        ret
le16_to_cpu_signed(unsigned char const*):
        movzx   eax, WORD PTR [rdi]
        ret