Qual é a maneira correta de converter 2 bytes em um inteiro assinado de 16 bits?

Em esta resposta , Zwol fez esta afirmação:

A maneira correta de converter dois bytes de dados de uma fonte externa em um número inteiro assinado de 16 bits é com funções 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;
}

Qual das funções acima é apropriada depende se a matriz contém uma pequena representação endian ou big endian. Endianness não é o problema em questão aqui, estou me perguntando por que o zwol subtrai 0x10000udo uint32_tvalor convertido para int32_t.

Por que essa é a maneira correta ?

Como evita o comportamento definido pela implementação ao converter para o tipo de retorno?

Como você pode assumir a representação do complemento de 2, como essa conversão mais simples falharia: return (uint16_t)val;

O que há de errado com esta solução ingênua:

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

Se intfor de 16 bits, sua versão dependerá do comportamento definido pela implementação se o valor da expressão na returninstrução estiver fora do intervalo int16_t.

No entanto, a primeira versão também tem um problema semelhante; por exemplo, se int32_tfor um typedef para inte os bytes de entrada forem ambos 0xFF, o resultado da subtração na instrução de retorno é o UINT_MAXque causa um comportamento definido pela implementação quando convertido em int16_t.

IMHO, a resposta à qual você vincula tem vários problemas importantes.

Isso deve ser pedanticamente correto e funcionar também em plataformas que usam representações de complemento de bit de sinal ou 1 , em vez do complemento usual de 2 . Supõe-se que os bytes de entrada estejam no 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;
}

Por causa da filial, será mais caro que outras opções.

O que isso realiza é que evita qualquer suposição sobre como a intrepresentação se relaciona com a unsignedrepresentação na plataforma. A conversão para inté necessária para preservar o valor aritmético de qualquer número que caiba no tipo de destino. Como a inversão garante que o bit superior do número de 16 bits seja zero, o valor será adequado. Então o unário -e a subtração de 1 aplicam a regra usual para a negação do complemento de 2. Dependendo da plataforma, INT16_MINainda poderá estourar se não couber no inttipo no destino, caso em que longdeve ser usado.

A diferença para a versão original na pergunta ocorre no tempo de retorno. Enquanto o original sempre subtrai 0x10000e o complemento do 2 permite que o excesso de sinal acondicionado o int16_talcance, esta versão tem o explícito ifque evita o acúmulo de sinal (que é indefinido ).

Agora, na prática, quase todas as plataformas em uso hoje usam a representação de complemento de 2. De fato, se a plataforma possui um padrão stdint.hque define int32_t, ela deve usar o complemento de 2 para isso. Onde essa abordagem às vezes é útil, é com algumas linguagens de script que não têm tipos de dados inteiros - você pode modificar as operações mostradas acima para flutuadores e isso dará o resultado correto.

Outro método - usando union:

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

No programa:

...
B2I16 conv;

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

first_bytee second_bytepode ser trocado de acordo com o modelo endian pequeno ou grande. Este método não é melhor, mas é uma das alternativas.

Os operadores aritméticos mudam e bit a bit - ou na expressão (uint16_t)data[0] | ((uint16_t)data[1] << 8)não funcionam em tipos menores que int, para que esses uint16_tvalores sejam promovidos para int(ou unsignedse sizeof(uint16_t) == sizeof(int)). Ainda assim, isso deve gerar a resposta correta, pois apenas os 2 bytes inferiores contêm o valor.

Outra versão pedanticamente correta para a conversão de big-endian em little-endian (assumindo CPU little-endian) é:

#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);
}

memcpyé usado para copiar a representação int16_te essa é a maneira compatível com os padrões. Esta versão também compila em 1 instrução movbe, consulte montagem .

Aqui está outra versão que depende apenas de comportamentos portáteis e bem definidos (o cabeçalho #include <endian.h>não é padrão, o código é):

#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;
}

A versão little-endian é compilada com uma movbeinstrução única clang, a gccversão é menos ideal, consulte assembly .

Quero agradecer a todos os colaboradores por suas respostas. Aqui está o que o trabalho coletivo se resume a:

1. De acordo com os Standard C 7.20.1.1 tipos inteiros exacta de largura : tipos uint8_t, int16_te uint16_tdeve usar representação de complemento de dois, sem quaisquer bits de preenchimento, de modo que os bits reais da representação são inequivocamente os das 2 bytes na matriz, na ordem especificada pela os nomes das funções.
2. calcular o valor não assinado de 16 bits com (unsigned)data[0] | ((unsigned)data[1] << 8)(para a versão little endian) é compilado em uma única instrução e gera um valor não assinado de 16 bits.
3. De acordo com o Padrão C 6.3.1.3 Inteiros assinados e não assinados : a conversão de um valor do tipo uint16_tem tipo assinado int16_tpossui um comportamento definido pela implementação se o valor não estiver no intervalo do tipo de destino. Nenhuma provisão especial é feita para tipos cuja representação é definida com precisão.
4. para evitar esse comportamento definido pela implementação, é possível testar se o valor não assinado é maior que INT_MAXe calcular o valor assinado correspondente subtraindo 0x10000. Fazer isso para todos os valores sugeridos por zwol pode produzir valores fora do intervalo int16_tcom o mesmo comportamento definido pela implementação.
5. testar o 0x8000bit explicitamente faz com que os compiladores produzam código ineficiente.
6. uma conversão mais eficiente sem um comportamento definido pela implementação usa punção de tipo por meio de uma união, mas o debate sobre a definição dessa abordagem ainda está aberto, mesmo no nível do Comitê do Padrão C.
7. punição de tipo pode ser executada de forma portável e com comportamento definido usando memcpy.

Combinando os pontos 2 e 7, aqui está uma solução portátil e totalmente definida que compila eficientemente uma única instrução com o gcc e o 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;
}

Conjunto 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