强制转换带来的疑惑
来源:互联网 发布:淘宝店买卖平台 编辑:程序博客网 时间:2024/05/17 08:12
int recv_message(sGsmRecvData *pRecvData){ int num = 0; int Index = 0; unsigned char u8Ret = FALSE; printf_func_line(); if((pRecvData == NULL) || (pRecvData->recv == NULL)) return -1; num = pRecvData->recv(pRecvData->s32Fd, pRecvData->pStrData, pRecvData->s32PStrDataSize); if(num > 0) { printf("pRecvData->pStrData:%s\n", pRecvData->pStrData); pRecvData->pStrData[pRecvData->s32PStrDataSize - 1] = '\0'; call_SMSfunc_set(pRecvData->pStrData, num, NULL); u8Ret = TRUE; } printf_func_line(); return u8Ret;}
原型:
int tty_read(int fd, char *buf, int buf_max_size);
早上在测试这个接收函数,发现一直出错,但是找不到问题在哪里。
就是调用后,会出现一些莫名其妙的问题。
后来检查了,sGsmRecvData的原型,发现里边之前pRecvData->s32PStrDataSzie 是pRecvData->u8PStrDataSize,
而函数指针指向的原型是int tty_read(int fd, char *buf, int buf_max_size);
考虑到这个缘故,将原来的修改为
num = pRecvData->recv(pRecvData->s32Fd, pRecvData->pStrData, (int)pRecvData->u8PStrDataSize);
发现这样的结果,依然是很糟糕,
没有结果,
后来实在找不到别的可以修改的,
就将原来的结构体中uchar 修改为了int 将u8PStrDataSize修改为s32PStrDataSzie ,
再次运行时,发现程序正常运行了。
如果直接调用函数时,使用强制类型转换,虽然不是很提倡,但是有时候为了需要还是使用,但是为什么在使用这个函数指针时,这样的强制转换就造成了程序运行错误。
考虑有这样几个因素,
这里的函数指针,和函数指针的参数,都来自同一个结构,有可能在强制转换时,由uchar转换为int发生了错误。
当然这个需要测试才能知道。
后来测试了一下,
发现刚才的猜测确实没有什么道理,
实际情况是给u8PStrDataSize 赋了一个1024(即:给一个uchar型,赋了一个1024肯定要超出的),超过了它自己的范围,在使用时丢失数据,只剩下低位的0,
造成了读数据时,缓冲区大小为0,应该是这个带来了之前的错误。并非是强制转换之错,而是无视数据类型之殇。
错在开始,而不在转换。
但是对于read函数而言,如果缓冲区大小为零,它会怎么处理呢?
经过测试,发现如果缓冲区大小为零,
则没什么影响,读回的大小就是0,
但是为什么会影响程序的运行呢?
- 强制转换带来的疑惑
- 常量的强制转换的疑惑const_cast<类型>(表达式)
- 浅析“强制类型转换”带来的性能分析及其解决方法
- Java参数重载带来的疑惑
- 强制关机带来的软件无法打开
- socket的recv和send带来的疑惑
- 编码的强制转换
- 数据类型的强制转换
- 指针的强制转换
- 对象的强制转换
- 强制的类型转换
- 强制类型的转换
- php的强制转换
- 指针的强制转换
- php的强制转换
- 类型转换带来的问题
- 类型转换带来的问题
- PDF转换成TXT的疑惑
- zoj 1392.The Hardest Problem Ever
- levenshtein_distance(字符串相似度算法)
- 31.黑马程序员-多线程(继承Thread)
- 项目管理者对管理的总结
- C语言如何获得精确到毫秒的时间
- 强制转换带来的疑惑
- const 和 define
- 32.黑马程序员-多线程(实现Runnable接口)
- 研究分析QQ木马的原理
- SIFT读书笔记
- linux rm指令
- C++程序设计-第八周上机实践项目
- 10进制、2进制、16进制的互转
- 33.黑马程序员-多线程(安全)