Який правильний спосіб перетворити 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_tє typedef для 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може бути замінено відповідно до малої чи великої ендіанської моделі. Цей спосіб не кращий, але є однією з альтернатив.

Арифметичні оператори зміщуються і порозрядно - або в виразі (uint16_t)data[0] | ((uint16_t)data[1] << 8)не працюють на типи, менші int, так що ці uint16_tзначення отримують int(або unsignedякщо 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