Jaki jest prawidłowy sposób konwersji 2 bajtów na 16-bitową liczbę całkowitą ze znakiem?

W tej odpowiedzi , Zwol wykonane tego twierdzenia:

Prawidłowym sposobem konwersji dwóch bajtów danych ze źródła zewnętrznego na 16-bitową liczbę całkowitą ze znakiem jest użycie funkcji pomocniczych takich jak to:

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

Która z powyższych funkcji jest odpowiednia, zależy od tego, czy tablica zawiera małą reprezentację endianową, czy dużą. Bajt nie jest sprawa na pytanie tutaj, zastanawiam się dlaczego Zwol odejmuje 0x10000uod uint32_twartości przekształca się int32_t.

Dlaczego to jest właściwy sposób ?

Jak uniknąć zachowania zdefiniowanego w implementacji podczas konwersji na typ zwracany?

Ponieważ możesz założyć reprezentację dopełniacza 2, dlaczego ta prostsza rzutowanie nie powiedzie się: return (uint16_t)val;

Co jest złego w tym naiwnym rozwiązaniu:

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

Jeśli intjest 16-bitowy, wówczas twoja wersja opiera się na zachowaniu zdefiniowanym przez implementację, jeśli wartość wyrażenia w returninstrukcji jest poza zakresem int16_t.

Jednak pierwsza wersja ma podobny problem; na przykład jeśli int32_tjest typedef dla int, a bajty wejściowe są oba 0xFF, to wynikiem odejmowania w instrukcji return jest to, UINT_MAXco powoduje zachowanie zdefiniowane w implementacji po przekonwertowaniu na int16_t.

IMHO odpowiedź, do której linkujesz, ma kilka poważnych problemów.

Powinno to być pedantycznie poprawne i działać również na platformach, które używają bitu znaku lub reprezentacji uzupełnienia 1 , zamiast zwykłego uzupełnienia 2 . Zakłada się, że bajty wejściowe są uzupełnieniem 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;
}

Ze względu na oddział będzie droższy niż inne opcje.

Osiąga to to, że pozwala uniknąć jakichkolwiek założeń dotyczących tego, jak to zrobić int powiązania unsignedreprezentacji z reprezentacją na platformie. Rzutowanie intjest wymagane, aby zachować wartość arytmetyczną dla dowolnej liczby pasującej do typu docelowego. Ponieważ inwersja zapewnia, że ​​górny bit 16-bitowej liczby będzie wynosił zero, wartość będzie pasować. Następnie jednostkowe -i odejmowanie 1 stosuje zwykłą regułę dla negacji uzupełnienia 2. W zależności od platformy INT16_MINmoże nadal przepełniać się, jeśli nie pasuje do inttypu na celu, w którym to przypadku longnależy użyć.

Różnica w stosunku do oryginalnej wersji w pytaniu pochodzi z czasu powrotu. Podczas gdy oryginał po prostu zawsze odejmował, 0x10000a dopełnienie 2 pozwalało podpisanemu przepełnieniu zawinąć go do int16_tzakresu, ta wersja ma wyraźne, ifże pozwala uniknąć podpisanego zawijania (które jest niezdefiniowane ).

W praktyce prawie wszystkie obecnie używane platformy używają reprezentacji uzupełnienia 2. W rzeczywistości, jeśli platforma posiada zgodny ze standardami stdint.h, który definiuje int32_t, to należy użyć 2 dopełnienie dla niego. Podejście to czasami się przydaje w przypadku niektórych języków skryptowych, które w ogóle nie mają liczb całkowitych - możesz zmodyfikować operacje pokazane powyżej dla liczb zmiennoprzecinkowych i da to poprawny wynik.

Inna metoda - użycie union:

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

W programie:

...
B2I16 conv;

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

first_bytei second_bytemogą być zamieniane według małego lub dużego modelu endian. Ta metoda nie jest lepsza, ale jest jedną z alternatyw.

Operatory arytmetyczne przesuwają się i bitowo - lub w wyrażeniu (uint16_t)data[0] | ((uint16_t)data[1] << 8)nie działają na typach mniejszych niż int, więc te uint16_twartości są promowane do int(lub unsignedjeśli sizeof(uint16_t) == sizeof(int)). Mimo to powinno to dać poprawną odpowiedź, ponieważ tylko 2 dolne bajty zawierają wartość.

Inną pedantycznie poprawną wersją konwersji z big-endian na little-endian (przy założeniu, że procesor little-endian) to:

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

memcpysłuży do skopiowania reprezentacji int16_ti jest to zgodny ze standardami sposób. Ta wersja kompiluje się również w 1 instrukcji movbe, patrz instrukcja montażu .

Oto kolejna wersja, która opiera się wyłącznie na przenośnych i dobrze zdefiniowanych zachowaniach (nagłówek #include <endian.h>nie jest standardem, kod jest):

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

Wersja Little-Endian kompiluje się do pojedynczej movbeinstrukcji clang, gccwersja jest mniej optymalna, patrz zestawienie .

Chcę podziękować wszystkim autorom za ich odpowiedzi. Oto, co sprowadza się do pracy zbiorowej:

1. Zgodnie z normą C 7.20.1.1 Typy liczb całkowitych o ścisłej szerokości : typy uint8_t,int16_t i uint16_tmuszą stosować uzupełnienie dwójkowe reprezentację bez bitów wypełniających, więc rzeczywiste bity reprezentacji są jednoznacznie te z 2 bajtów w tablicy, w kolejności określonej przez nazwy funkcji.
2. obliczenie 16-bitowej wartości bez znaku za pomocą (unsigned)data[0] | ((unsigned)data[1] << 8)(dla małej wersji Endian) kompiluje się do pojedynczej instrukcji i daje 16-bitową wartość bez znaku.
3. Zgodnie ze standardem C 6.3.1.3 Liczba całkowita ze znakiem i bez znaku : konwersja wartości typu uint16_tna typ podpisany int16_tma zachowanie zdefiniowane w ramach implementacji, jeśli wartość nie mieści się w zakresie typu docelowego. Nie przewiduje się specjalnych przepisów dla typów, których reprezentacja jest dokładnie zdefiniowana.
4. aby uniknąć tego zachowania zdefiniowanego w implementacji, można przetestować, czy wartość bez znaku jest większa niż, INT_MAXi obliczyć odpowiednią wartość ze znakiem odejmując 0x10000. Wykonanie tej czynności dla wszystkich wartości sugerowanych przez zwolnienie może wygenerować wartości poza zakresem o int16_ttym samym zachowaniu zdefiniowanym dla implementacji.
5. testowanie dla 0x8000 bitu wyraźnie powoduje, że kompilatory wytwarzają nieefektywny kod.
6. bardziej wydajna konwersja bez zdefiniowanego zachowania implementacyjnego wykorzystuje wykrywanie czcionek za pomocą unii, ale debata dotycząca zdefiniowania tego podejścia jest nadal otwarta, nawet na poziomie komitetu C Standard.
7. kasowanie typu może być wykonywane przenośnie i ze zdefiniowanym zachowaniem za pomocą memcpy.

Łącząc punkty 2 i 7, oto przenośne iw pełni zdefiniowane rozwiązanie, które skutecznie kompiluje się do pojedynczej instrukcji z gcc i 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;
}

Montaż 64-bitowy :

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