2

我在 Desktop x64 Intel 架构（gcc 编译器、linux）和 RaspberryPi Arm（gcc 交叉编译器）上运行以下代码。

quint32 id;

id=((quint32)ref[1]);
id|=((quint32)ref[2])<<8;
id|=((quint32)ref[3])<<16;
id|=((quint32)ref[4])<<24;

其中ref是一个QByteArray。

我注意到，尽管强制转换 quint32（它是无符号整数），但当给定字节为负数时，我的 PC 会执行导致错误的符号扩展。我的代码在 Arm 上运行良好。为什么会发生这种情况？我认为铸造应该防止这种情况。不是吗？

   id|=((quint32)ref[4])<<24;

拆卸：

    mov    -0x160(%rbp),%rax
    mov    $0x4,%esi
    mov    %rax,%rdi
    callq  0x425af0 <QByteArray::operator[](int)>
    mov    %rax,%rcx
    mov    %edx,%eax
    mov    %rcx,-0x170(%rbp)
    mov    %eax,-0x168(%rbp)
    mov    -0x170(%rbp),%rax
    mov    %rax,-0x40(%rbp)
    mov    -0x168(%rbp),%rax
    mov    %rax,-0x38(%rbp)
    lea    -0x40(%rbp),%rax
    mov    %rax,%rdi
    callq  0x425aa0 <QByteRef::operator char() const>

    movsbl %al,%eax                                     #sign extension.

    shl    $0x18,%eax
    or     %eax,-0x148(%rbp)

我还注意到，编译器使用 QByteRef 返回值而不是 char。但我猜它不应该导致任何错误。

来自QByteArray帮助页面：

QByteRef    operator[](int i)
char    operator[](int i) const
QByteRef    operator[](uint i)
char    operator[](uint i) const

提前致谢

4

1 回答 1

2

当从有符号转换char为unsigned int（或其他更大的无符号类型）时，语言指定符号扩展首先发生。为避免这种情况，请将chartounsigned char作为您的第一步。你不应该需要任何其他演员 - 大小的增加应该自动发生。

于 2014-03-23T09:32:58.880 回答