Как правильно преобразовать 2 байта в 16-разрядное целое число со знаком?

В этом ответе , zwol сделал это заявление:

Правильный способ преобразования двух байтов данных из внешнего источника в 16-разрядное целое число со знаком - с помощью вспомогательных функций, таких как:

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

Какая из вышеуказанных функций подходит, зависит от того, содержит ли массив представление с прямым или обратным порядком байтов. Порядок байтов не является проблемой на вопрос здесь, я задаюсь вопросом, почему zwol вычитает 0x10000uиз uint32_tзначения преобразуются в int32_t.

Почему это правильный путь ?

Как избежать поведения, определенного при реализации, при преобразовании в тип возвращаемого значения?

Так как вы можете предположить представление дополнения 2, как это простое приведение завершится неудачно: return (uint16_t)val;

Что не так с этим наивным решением:

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

Если int16-битный, то ваша версия опирается на поведение, определяемое реализацией, если значение выражения в returnвыражении выходит за пределы диапазона int16_t.

Однако первая версия также имеет аналогичную проблему; например, если int32_ttypedef для int, а входные байты оба 0xFF, то результатом вычитания в операторе return является то, UINT_MAXчто вызывает поведение, определяемое реализацией, при преобразовании в int16_t.

ИМХО ответ, на который вы ссылаетесь, имеет несколько основных проблем.

Это должно быть педантично правильным и работать также на платформах, которые используют знаковый бит или представления дополнения 1 вместо обычного дополнения 2 . Предполагается, что входные байты находятся в дополнении 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;
}

Из-за ветки, это будет дороже, чем другие варианты.

Это позволяет избежать каких-либо предположений о том, как intпредставление относится к unsignedпредставлению на платформе. Приведение к intтребуется для сохранения арифметического значения для любого числа, которое будет соответствовать целевому типу. Поскольку инверсия гарантирует, что старший бит 16-разрядного числа будет равен нулю, значение будет соответствовать. Тогда унарное -и вычитание 1 применяют обычное правило для отрицания дополнения 2. В зависимости от платформы INT16_MINможет все еще переполниться, если он не соответствует intтипу на цели, и в этом случае longследует использовать.

Разница с оригинальной версией в вопросе приходит во время возврата. В то время как оригинал всегда всегда вычитался, 0x10000а дополнение 2 позволяло знаменному переполнению переносить его в int16_tдиапазон, в этой версии есть явное, ifкоторое избегает подписанного переноса (который не определен ).

Сейчас на практике почти все платформы, используемые сегодня, используют представление дополнения 2. Фактически, если у платформы есть совместимый со стандартом, stdint.hкоторый определяет int32_t, это должно использовать дополнение 2 для этого. Иногда этот подход оказывается полезным при использовании некоторых языков сценариев, которые вообще не имеют целочисленных типов данных - вы можете изменить операции, показанные выше для чисел с плавающей запятой, и это даст правильный результат.

Другой метод - использование union:

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

В программе:

...
B2I16 conv;

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

first_byteи second_byteможет быть заменен в соответствии с маленькой или большой байтовой моделью. Этот метод не лучше, но является одной из альтернатив.

Арифметические операторы shift и bitwise-or в выражении (uint16_t)data[0] | ((uint16_t)data[1] << 8)не работают с типами, меньшими чем int, так что эти uint16_tзначения повышаются до int(или unsignedif sizeof(uint16_t) == sizeof(int)). Тем не менее, это должно дать правильный ответ, так как только младшие 2 байта содержат значение.

Еще одна педантически правильная версия для преобразования с прямым порядком байтов в младший (если предполагается, что процессоры с прямым порядком байтов):

#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используется для копирования представления, int16_tи это является стандартным способом сделать это. Эта версия также компилируется в 1 инструкцию movbe, см. Сборку .

Вот еще одна версия, которая опирается только на переносимое и четко определенное поведение (заголовок #include <endian.h>не стандартный, код такой):

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

Версия с прямым порядком байтов компилируется в одну movbeинструкцию clang, gccверсия менее оптимальна, см. Сборку .

Я хочу поблагодарить всех авторов за их ответы. Вот к чему сводится коллективная работа:

1. В соответствии с C Стандарт 7.20.1.1 Точной шириной целых типов : типы uint8_t, int16_tиuint16_t должен использовать комплемент представление двоичного без каких - либо бит заполнения, так что фактические биты представления однозначно являются те , из 2 -х байт в массиве, в порядке , определенном имена функций.
2. вычисление 16-разрядного значения без знака с помощью (unsigned)data[0] | ((unsigned)data[1] << 8)(для версии с прямым порядком байтов) компилируется в одну инструкцию и дает 16-разрядное значение без знака.
3. Согласно стандарту C 6.3.1.3 Целые числа со знаком и без знака : преобразование значения типа uint16_tв тип со знаком int16_tимеет поведение, определяемое реализацией, если значение не находится в диапазоне типа назначения. Специальных положений для типов, представление которых точно определено, не предусмотрено.
4. Чтобы избежать этого поведения, определенного реализацией, можно проверить, больше ли значение без знака, INT_MAXи вычислить соответствующее значение со знаком путем вычитания 0x10000. Выполнение этого для всех значений, как предложено zwol, может привести к значениям вне диапазона int16_tс таким же поведением, определенным реализацией.
5. проверка на 0x8000бит явно приводит к тому, что компиляторы создают неэффективный код.
6. более эффективное преобразование без определенного поведения реализации использует наказание типов через объединение, но дебаты относительно определенности этого подхода все еще открыты, даже на уровне комитетов стандарта C.
7. Пуннинг типа может быть выполнен переносимым и с определенным поведением, используя memcpy.

Комбинируя пункты 2 и 7, вот переносимое и полностью определенное решение, которое эффективно компилируется в одну инструкцию с использованием gcc и 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;
}

64-битная сборка :

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