rtt的断言RT_ASSERT在关闭debug的情况下是不是有问题？
RT_ASSERT的定义是：#ifdef RT_DEBUG
#define RT_ASSERT(EX) if (!(EX)) {volatile char dummy=0; rt_kprintf("(%s) assert failed at %s:%d \n", \
#EX, __FUNCTION__, __LINE__); while (dummy==0);}
#else
#define RT_ASSERT(EX)
#endif
在内核代码和我自己的代码里面 很多地方用RT_ASSERT来检查空指针，
也就是说 如果关闭了RT_DEBUG宏 那么很多代码里面对空指针的检查就完全失效了？
如果在实际产品中 这是否是一个隐患？
目前 我自己是将其修改为
#define RT_ASSERT(EX) if (!(EX)) return (-RT_ERROR) release版本才去掉，debug版本建议都打开RT_DEBUG。 是阿 就是考虑在release的时候要关闭所有的打印输出的说 ：） 定义为空就屏蔽了所有的ASSERT信息。
通常，在进入到产品的时候，应该保证系统不会出现任何的ASSERT，所以才能够把定义成空。 LZ对ASSERT理解有误吧？
ASSERT只用于debug过程检查可预见的异常情况，不应该用于影响程序正常流程的判断（中了ASSERT程序就要停止运作，进入死循环等待debug）。所以当release的时候，ASSERT完全去掉也不应该影响程序的正常运作。 但是我看到很多rtt内核的代码 检查空指针都是用的断言，而不是空指针返回的机制
这样从安全的角度来说 似乎不是很好？ 是LZ没能理解，正常情况下，指针不能为空的，为空说明出现了意外，显示错误信息后你应该改正这个错误
如果需要空指针返回的功能，就不要用断言，更不应该乱改已有的宏。。。
或者你改了以后永远不要贴出来，自己用就好。。。 回复【5楼】mail2li
但是我看到很多rtt内核的代码 检查空指针都是用的断言，而不是空指针返回的机制
这样从安全的角度来说 似乎不是很好？
-----------------------------------------------------------------------
例如rt_err_t rt_device_open(rt_device_t dev, rt_uint16_t oflag)为例，参数dev肯定不能为NULL，如果NULL肯定是用户代码写错了，于是进入rt_device_open函数的第一件事就是RT_ASSERT(dev != RT_NULL);。
当debug完，可以release的时候，证明程序运作正常，RT_ASSERT的情况没有发生过，那么就将所有RT_ASSERT去除，提高效率。
第二个问题，为什么不是空指针返回？因为空指针返回很可能会让错误“溜掉”，扰乱程序正常逻辑，反而让调试难度大增。其次，大量的判断也会影响运行效率，在每个指令开销都要计算着的嵌入式系统来说，这个代价有点大。 回复【7楼】gzhuli咕唧霖
-----------------------------------------------------------------------
我明白了
不过俺们的QA只认MISRA的机器检查 T__T
页:
[1]