符号幅度转补码的C代码测试失败，请求排查（输入为short类型）

原代码的核心问题是未处理short转int时的符号扩展，导致幅度提取错误。输入为short类型的符号幅度值，传入int参数时会自动符号扩展（若符号位为1，int的高16位会被填充为1），这使得后续计算的幅度值包含无效的高位1，最终输出错误的补码结果。

修正后的代码 #

int magtoComp(int x) {
    // 截断输入到16位，消除符号扩展的影响，还原原始符号幅度值
    x &= 0xFFFF;
    // 提取符号位：正数为0，负数为全1（0xFFFFFFFF）
    int mask = x >> 15;
    // 提取低15位的幅度值
    int mag = x & 0x7FFF;
    // 正数直接返回幅度，负数返回幅度的补码（~mag + 1）
    return (mag ^ mask) + (~mask + 1);
}

关键逻辑说明 #

• 截断处理：x &= 0xFFFF确保只保留输入的低16位（short的原始符号幅度数据），避免符号扩展带来的高位干扰。
• 符号位扩展：x >> 15利用有符号整数右移的特性，将符号位扩展到整个int位宽，正数得到全0，负数得到全1。
• 补码计算：
  • 正数场景：mask为0，(mag ^ 0) + (~0 + 1)等价于mag + 0，直接返回幅度值（与补码一致）。
  • 负数场景：mask为全1，mag ^ mask等价于对幅度值按位取反，~mask + 1等价于加1，最终得到幅度值的补码（即对应负数的补码表示）。

测试验证用例 #

• 符号幅度+5（0x0005）→ 补码输出5，正确。
• 符号幅度-5（0x8005）→ 补码输出-5（0xFFFFFFFB），正确。
• 符号幅度-0（0x8000）→ 补码输出0，符合补码对0的统一表示，正确。
• 符号幅度-32767（0xFFFF）→ 补码输出-32767（0xFFFF8001），正确。

内容的提问来源于stack exchange，提问作者MikeJay_CodingJav