Linux socket 编程遇到问题

[阿基米东]

背景：想在PC机和ARM上建立TCP通讯，自定义了简单的协议，PC机作为服务端，ARM作为客户端。通过填写字符数组来完成，因此不存在大小端和字节对齐问题。PC机发到ARM端数据正常，但ARM端发给PC机的部分数据前莫明地加上了ffffff。以下是部分截图：
服务端（PC机）处理发送事件的进程：

服务端（PC机）处理接收事件的进程：

客户端（ARM）处理发送事件的进程：

客户端（ARM）处理接收事件的进程：


服务端和客户端的TCP连接按照正常的socket、bind、listen、accept、connect等流程进行，对于ASCII字符的传输（如：abcdefg、1234567）没有异常，但是对于自定义的协议，因为设计了开始标志0xAA、结束标志0xEE等，似乎当字符最高位为1时就会添加ffffff，测试结果如下：
服务端（PC机）：

客户端（ARM）：


也许值得说明的是：我的PC机上装的是64位的ubuntu系统，ARM板跑的是32位的Linux系统。而当我将服务端程序编译到另一块32位系统的ARM板时，两个ARM的通信是正常的，不会在前面添加ffffff。可是在我目前的了解，64位的Linux和32位的区别，似乎只是指针和long类型占8字节，对于char并没有影响。如果各位前辈有了解该情况，麻烦指点一下小弟，谢谢！

[ma100]

buffer 定义是什么, 是否为 max_len+1 把字节对齐关掉试试 arm的char默认是unsigned char

[ipqtjmqj]

隐式转换而已，用%x需要转成整数，有符号字符型转成整数会根据最高位将其他位添0或添1

[ipqtjmqj]

看这个帖子

[阿基米东]

引用 2 楼 ipqtjmqj 的回复:

隐式转换而已，用%x需要转成整数，有符号字符型转成整数会根据最高位将其他位添0或添1

那么，为什么ARM端同样用%x打印，却不会出现前面的ffffff ？

[阿基米东]

引用 1 楼 ma100 的回复:

buffer 定义是什么, 是否为 max_len+1
把字节对齐关掉试试
arm的char默认是unsigned char

对的，buffer 的定义为： char buffer[MAXBUF + 1];
我是直接给字符数组赋值的，没有多字节类型数据，应该是不存在字节对齐问题的。
另外，我试了一下，确实跟 unsigned char 类型有关。测试代码如下：

PC机的运行结果：

ARM板的运行结果：


这样看来，用 unsigned char 的确解决了问题。但是用的都是gcc编译器，而我们平常说C语言的默认数据类型是有符号的，为什么ARM的char默认是无符号的呢？

[ipqtjmqj]

引用 4 楼 luckydarcy 的回复:

[quote=引用 2 楼 ipqtjmqj 的回复:] 隐式转换而已，用%x需要转成整数，有符号字符型转成整数会根据最高位将其他位添0或添1

那么，为什么ARM端同样用%x打印，却不会出现前面的ffffff ？[/quote] 1楼说了，arm的默认是无符号的，至于为什么是无符号的，因为编译器不同，至于为什么不同，只能去问编译器的设计者了

[阿基米东]

大概明白了，我总结一下，看看有没有错： （1）C语言的数据类型没有规定默认是signed还是unsigned，这取决于编译器的实现。 （2）打印0xAA的时候之所以显示ffffffaa，是因为%x默认输出32位整数，而变量类型刚好是signed char，并且最高位为1，所以会在其前面添加1补齐32位。 （3）同样，在if(buffer[0] == 0xAA)判断时，编译器会把0xAA这个值当做32位整数（sizeof(0xAA)等于4），因此在进行判断时将buffer[0]进行了隐式转换，实际上计较的是0xffffffaa和0x000000aa，所以为false。 （4）对于上述问题，将buffer的定义显式地定义为无符号字符数组即可解决，即：unsigned char buffer[MAXBUF + 1];。