如何在可移植的C代码中将“uint8_t”转换为“sint8_t”的最佳方法。
这是我想出的代码....
#include <stdint.h>
sint8_t DESER_SINT8(uint8_t x)
(
return
(sint8_t)((x >= (1u << 8u))
? -(UINT8_MAX - x)
: x);
)
#include <stdint.h>
int8_t DESER_INT8(uint8_t x)
(
return ((x >= (1 << 7))
? -(UINT8_MAX - x + 1)
: x);
)
1u << 8u 是 0x100u，大于所有uint8_t值，因此条件从未得到满足。你的“转换”过程实际上只是：
return x;
实际上这是有一定道理的。
您需要更清晰地定义您想要进行转换的内容。C99将从无符号整数类型到有符号整数类型的转换定义如下（§6.3.1.3“有符号和无符号整数”）
当带整数类型的值被转换为除
_Bool之外的其他整数类型时，如果该值可以由新类型表示，则其不变。...
否则，新类型为有符号类型，而且该值无法在其中表示;结果是具体实现定义的，或者引发具体实现定义的信号。
因此，0和127之间的uint8_t值将被保留，对于大于127的值的行为是未定义的。许多（但并非所有）实现将简单地将无符号值解释为有符号整数的二进制补码表示。也许你真正想知道的是如何在各个平台上保证这种行为？
如果是这样，您可以使用：
return x < 128 ? x : x - 256;
x - 256是一个int类型，保证将x解释为补码8位整数。 随后对int8_t进行隐式转换可保留此值。
以上假设应理解为int8_t，因为不是标准类型。如果不是，则所有赌注都取消了，因为我建议的转换的正确性取决于int8_t具有二进制补码表示形式的保证（§7.18.1.1“精确宽度整数类型”）。#include <stdint.h>
int8_t alf(uint8_t x) {
return x;
}
int8_t steve(uint8_t x) {
return x < 128 ? x : x - 256;
}
int8_t david(uint8_t x) {
return (x ^ 0x80) - 0x80;
}
使用 -Os 和 -fomit-frame-pointer 编译得到以下结果：
_alf:
0000000000000000 movsbl %dil,%eax
0000000000000004 ret
_steve:
0000000000000005 movsbl %dil,%eax
0000000000000009 ret
_david:
000000000000000a movsbl %dil,%eax
000000000000000e ret
请注意，优化后所有三种实现是相同的。 Clang / LLVM 给出完全相同的结果。 同样，如果我们构建ARM而不是x86：
_alf:
00000000 b240 sxtb r0, r0
00000002 4770 bx lr
_steve:
00000004 b240 sxtb r0, r0
00000006 4770 bx lr
_david:
00000008 b240 sxtb r0, r0
0000000a 4770 bx lr
保护你的实现，使其在没有成本的“常规”情况下免受边缘情况的影响，从来不是“愚蠢”的。
对于认为这样做增加了无谓的复杂性的观点，我要说：哪个更难——写一个注释来解释转换及其存在的原因，还是你的继任者的实习生在10年后尝试调试问题，当一个新的编译器打破了你一直默默依赖的幸运巧合时？维护以下内容真的那么难吗？
// The C99 standard does not guarantee the behavior of conversion
// from uint8_t to int8_t when the value to be converted is larger
// than 127. This function implements a conversion that is
// guaranteed to wrap as though the unsigned value were simply
// reinterpreted as a twos-complement value. With most compilers
// on most systems, it will be optimized away entirely.
int8_t safeConvert(uint8_t x) {
return x < 128 ? x : x - 256;
}
说了那么多，我同意这有点过头了，但我认为我们应该试着直接回答问题。当然，更好的解决方案是C标准明确规定无填充的二进制补码整数类型（即所有intN_t类型）从无符号类型转换为有符号类型时的行为。
127 是一个有效的值，而 -129 不是。因此 x < 128? x : x - 256。 - Potatoswatter256的类型是int，因此从uint8_t中减去它会得到一个int结果(§6.3.1.8“Usual arithmetic conversions”)，并且不是无操作。 - Stephen Canonuint8_t是一种无符号8位类型。int8_t是一种二进制补码8位类型。然而，从uint8_t转换到int8_t会饱和而不是循环。这并没有违反标准的任何部分，也没有什么是如此不可能以至于你可以将其视为“愚蠢”。 - Stephen Canonuint8_t转换为int8_t实际上是颠倒了两个半范围的顺序。 "高"数字变成了"低"数字。这可以通过使用异或运算来完成。
x ^ 0x80
然而，所有数值仍然为正。这不好。我们需要引入适当的符号并恢复适当的数量级。
return ( x ^ 0x80 ) - 0x80;
就这样！
我不知道这是否有任何实际价值，但以下是我想到的一种不同的方法：
uint8_t input;
int8_t output;
*(uint8_t *)&output = input;
int8_t 必须使用二进制补码表示。我唯一能想到这种推理不成立的情况是 CHAR_BIT>8 并且 8 位整数类型是带有陷阱位的扩展整数类型，该陷阱位会标志该值是有符号还是无符号。然而，以下明确使用 char 类型的类似代码永远不可能失败：
unsigned char input;
signed char output;
*(unsigned char *)output = input;
因为char类型不能有填充/陷阱位。
一个潜在的变体可能是：
return ((union { uint8_t u; int8_t s; }){ input }).s;
char类型：return ((union { unsigned char u; signed char s; }){ input }).s;
编辑： 正如Steve Jessop在另一个答案中指出的那样，如果存在填充位，则需要使用int8_t和uint8_t，因此它们的存在意味着CHAR_BIT==8。 所以我相信这种方法是有效的。话虽如此，我仍然永远不会使用uint8_t，而是始终明确使用unsigned char，以防实现将uint8_t实现为等大小扩展整数类型，因为char类型对于别名规则和类型转换具有特殊优势，使它们更加可取。
sint8_t 和 uint8_t 可以相互赋值，那么这个代码可以工作。sint8_t DESER_SINT8(uint8_t x) { return x; }
[conv.int]，该规则指出：“如果目标类型是有符号的，并且该值可以在目标类型（和位域宽度）中表示，则该值不变；否则，该值是实现定义的。” - Ben Voigt嗯，我想你试图返回x，如果x可以用sint8表示，或者abs（SINT8_MAX-x）如果不行，对吧？
在这种情况下，这是一个可行的方案（我认为你的有一个小错误）：
#define HIGHBIT(X) ((X) & (1 << (sizeof(X) * 8 - 1)))
char utos8(unsigned char ux)
{
return HIGHBIT(ux) ? -ux : ux;
}
CHAR_BIT == 8。 - Stephen Canonuint8_t，那么CHAR_BIT就是8。这是因为uint8_t被定义为具有8位宽度和无填充位。因此，CHAR_BIT必须能够被8整除，并且不能小于7，因此恰好为8。 - Steve JessopCHAR_BIT>=8，而不仅仅是>=7。所以可被整除性并非必需；只需满足8<=CHAR_BIT<=8即可推断出CHAR_BIT==8。 - R.. GitHub STOP HELPING ICEint selector= 127 - x; // 0 or positive if x <=127, negative otherwise
int selector>>= 8; // arithmetic rotate to get -1 or 0
int wrapped_value= x - 256;
return (x&~selector)|(wrapped_value&selector); // if selector is 0, use x, otherwise, use the wrapped value.
假设您的sint8_t实际上是来自<stdint.h>的int8_t，那么它保证是二进制补码形式，并且保证没有填充位。
进一步假设您希望相反（隐式）转换起作用并产生原始值。
那么，给定类型为uint8_t的值v，您所要做的就是...
int8_t( v )
就是这样。
据我所知，C标准不保证这种转换，只保证相反的转换。然而，没有已知的系统或编译器不能工作（假设您有这些类型可用）。
忘记所有手动位操作。或者，为了测试您是否正确地进行了转换，只需将该值分配给uint8_t并检查在所有情况下是否获得原始值。特别是，您使用的公式产生-((2^n-1)-x)=1+x-2^n，而值保留的正确转换是x-2^n。
干杯 & hth.，
– Alf
bool的C++实现一样无关紧要。我们不为此编写解决方法。请记住，根据C99定义，int8_t是二进制补码。并且请记住，要求使用二进制补码形式的原因正是为了支持这种转换。;-) - Cheers and hth. - Alfmemcpy 解决方案是有效的，就像我给出的基于类型转换的解决方案一样。 - R.. GitHub STOP HELPING ICE
x > 127，自动转换具有实现定义的行为。 - Stephen Canon