2バイトを符号付き16ビット整数に変換する正しい方法は何ですか？

では、この答え、zwolはこの主張をしました。

2バイトのデータを外部ソースから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);
}

Ifはint16ビットである中での発現の値ならば、あなたのバージョンでは、処理系定義の動作に依存しているreturn文がの範囲外ですint16_t。

ただし、最初のバージョンにも同様の問題があります。たとえば、int32_tがtypedef for intで、入力バイトが両方0xFFの場合、returnステートメントでの減算の結果は、UINT_MAXに変換されint16_tたときに実装定義の動作になります。

私があなたがリンクする答えにいくつかの主要な問題があります。

通常の2の補数ではなく、符号ビットまたは1の補数表現を使用するプラットフォームでもこれは問題なく正しく、機能するはずです。入力バイトは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を定義する標準に準拠している場合、2の補数を使用int32_tする必要があります。このアプローチが役立つ場合があるのは、整数データ型をまったく持たない一部のスクリプト言語の場合です。上記の浮動小数点演算を変更すると、正しい結果が得られます。

別の方法-使用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ほとんど、またはビッグエンディアンモデルに応じて交換することができます。この方法は良くありませんが、代替手段の1つです。

算術演算子shiftとbitwise-or in expression (uint16_t)data[0] | ((uint16_t)data[1] << 8)はint、より小さいタイプでは機能しないため、これらのuint16_t値はint（またはunsignedifにsizeof(uint16_t) == sizeof(int)）昇格されます。それでも、値が含まれるのは下位2バイトだけなので、これで正しい答えが得られるはずです。

ビッグエンディアンからリトルエンディアンへの変換（リトルエンディアンのCPUを想定）のための別の正確なバージョン：

#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のとおり、Exact-width integer types：types uint8_t、int16_tおよびuint16_tパディングビットなしの2の補数表現を使用する必要があるため、表現の実際のビットは、配列内の2バイトのビットであり、関数名。
2. (unsigned)data[0] | ((unsigned)data[1] << 8)（リトルエンディアンバージョンの）を使用して符号なし16ビット値を計算すると、単一の命令にコンパイルされ、符号なし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