文档介绍：公司常见软件编程低级错误:内存越界C语言软件编程规范工作组前言这套材料作为编程规范的辅助材料,帮助大家理解编程规范背后的原理。C和C++语言是我司的主流编程语言,然而C/C++具有很多强大的语言特性,从而导致C/C++非常复杂,使得代码更容易出现BUG、难以阅读和维护。业界知名的编程规范都对C/C++容易出现问题的语言特性进行管理。例如MISRA(汽车工业软件可靠性联合会)制定的1998版的MISRAC规范指出,一些在C看来可以接受,却存在隐患的地方有127处之多。2004版的MISRAC规范将针对C语言的规则增加到了141条。对于程序员来说,能工作的代码并不等于“好”代码。“好”代码的指标很多,包括可读性、可维护性、可移植性和可靠性等。出现网上问题的代码,大多数是不良编程****惯引起的。不遵守编程规范的代码,往往也是最不可靠的代码。本胶片收集了常见的内存越界案例,给出了相应的纠正措施。对应的编程规范:防止内存操作越界常见的内存越界问题和解决措施建议数组分配未考虑最大情况,导致空间不够【问题描述】透明消息下发处理导致网上单板复位【问题定位】当消息发送失败后的异常处理流程中,存在局部数据越界,导致别的任务在使用错误的堆栈信息时,发生数据访问异常,而单板复位。 UINT8aucErrMsg[128]="\0";/*用于返回错误信息字符串*/ ulRet=VOS_SendMsg(pMsgBlock); if(VOS_OK!=ulRet) { VOS_sprintf((CHAR*)aucErrMsg,"\r\nDBG_SimExternalMsgAct:VOS_SendMsgfail!ulRet(%u),ulSenderCpuId(0x%x),ulSenderPid(%u),ulReceiverCpuId(0x%x),ulReceiverPid(%u)", ulRet, pMsgBlock->ulSenderCpuId, pMsgBlock->ulSenderPid, pMsgBlock->ulReceiverCpuId, pMsgBlock->ulReceiverPid); }%u输出的十进制无符号整数,范围0~4294967295,长度1~11位不定,随着程序的运行,数值会越来越大,从1位数变成2位数,3位数,……,11位数等,导致内存越界。同样%x的长度最大可以达到8位。aucErrMsg的长度最大应该为:120(字符长度)+3*11(3个无符号整数长度%u)+2*8(2个十六进制整数长度%x)=169,不是128.【纠正措施】将数组aucErrMsg大小定义扩大为256。【举一反三】数组的大小要考虑最大情况,避免数组分配空间不够。数组分配未考虑最大情况,导致空间不够(续一)【问题描述】实时性能统计,可选指标达到最大,单击"保存设置",造成网管实时性能后台重启【问题定位】代码的数组长度为256字节,当选择满20个指标时,字符串长度为276个,造成栈空间越位。【纠正措施】C语言:把字符串缓冲区改正1024个字节长度;C++:使用相应的类库std::string等。【举一反三】多大的缓冲区才是安全的?对C来说,要考虑到各种应用场合,特别是考虑到函数参数的边界条件,按最大的可能分配空间。能够程序计算的,尽量自动计算。对C++而言,不要使用C语言风格的数组、指针运算和内存管理原语操作实现数组,使用vector或者string,请把这种复杂的体力劳动交给类库吧!数组分配未考虑最大情况,导致空间不够(续二)【问题描述】数据库刷新间隔设为值1073741823时,系统监控后台coredump,监控前台抛异常。【问题定位】使用itoa()将整型数转换为字符串时:charszTempShold[10];itoa(usProcFrecy,szTempShold,10);szTempShold是以‘\0’结尾的字符数组,只能存储9个字符,而usProcFrecy的最大值可达到10位,导致符数组szTempShold越界。【纠正措施】将数组设置成12位【举一反三】按最大的可能分配空间,一个int(32位)在-2147483647~2147483648之间,使用itoa函数安全的分配空间是12位。使用危险函数操作字符串【问题描述】发送短消息的时候进程COREDUMP【问题定位】使用了一个1024个字节的字符数组进行sprintf格式化操作,当告警发送数量比较大,写入日志的字符串很长,内存越界【纠正措施】将sprintf替换成安全函数snprintf,指定缓冲区大小,确保内存不会越界【举一反三】C语言提供的字符串库函数sprintf/vsprintf/strcpy/strcat/gets等非常危险,很容易导致内存越界,应该使用安全的字符串库函数snprintf